Некоторые люди могут считать, что у них лучшая настройка веб-сервера. Сейчас он может работать гладко, но что произойдет, когда он будет полностью загружен? Ваш сервер все еще работает в лучшем виде? Возможно нет. Что нужно, чтобы иметь лучшие серверы?

Я думаю, что Nielsen провела опрос несколько лет назад, в котором говорилось, что через восемь секунд любой на веб-странице перешел бы в другое место, если бы у него была альтернатива. Восемь секунд не кажутся долгим сроком, но вы знаете, я бы до сих пор не занимался тем, что делаю, если бы не было много проблем с производительностью на веб-серверах и серверах приложений, и это не просто Холодный синтез." — Майк Брант, CF Whisperer

Как сказал Майк, с веб-серверами происходит много проблем, в том числе и с CF. К счастью, мы можем предпринять некоторые шаги для оптимизации производительности наших веб-приложений и серверов ColdFusion. Взглянув на эти 4 основные области, вы сможете убедиться, что ваши серверы CF и приложения работают максимально эффективно.

В этой статье вы узнаете:

  1. Как настроить JVM
  2. Как настроить сборщик мусора
  3. Различные шаги для настройки производительности
  4. Как улучшить коннектор веб-сервера

Шесть ключевых областей, которыми должны овладеть ИТ-директора

Возможно, одной из самых важных целей для вас является оптимальное время безотказной работы и производительность сервера. Это ежедневная задача, которую необходимо решать, чтобы ваши серверы и приложения всегда работали без сбоев. Есть шесть ключевых направлений деятельности, которыми должен заниматься каждый ИТ-директор для достижения этой цели.

Оптимизация ваших серверов и производительности может потребовать некоторой работы. Но в долгосрочной перспективе вы будете намного счастливее, чем вы это сделали.

JVM означает виртуальную машину Java. JVM была сердцем Adobe ColdFusion со времен MX (ColdFusion 6). За это время ColdFusion был оптимизирован для обеспечения безопасности и переносимости, полностью переписанный внутри Java Runtime Environment. Java — это корень ColdFusion. Поэтому, когда дело доходит до внесения корректировок, имеет смысл начинать только с источника. JVM строится аналогично луковице, в которой построены слои, в которых построена виртуальная машина. В основе лежит сервер приложений Java или ColdFusion. Это ядро ​​находится внутри контейнера сервлета. Этот контейнер сервлета ранее был конструкцией Adobe, известной как JRun. Однако начиная с ColdFusion 10 контейнер сервлета переключается на Tomcat. Tomcat имеет значительные преимущества перед JRun, в том числе:

Следующий слой — это сама Виртуальная машина Java. JVM состоит из сервлета (сейчас) и сервера приложений Java (ColdFusion). Все это надежно закреплено в вашей операционной системе. Эта удобная инфографика от cfguide.io аккуратно отображает организацию.

Теперь, когда вы знаете, как организована JVM, вы должны знать некоторые основы того, как она работает, чтобы начать настройку. Первое, что нужно понять, это то, как JVM использует выделенную память. Он разбивает память на сегменты, называемые поколениями. Различают 3 основных поколения.

И молодое, и старое поколение обрабатывают код вашего приложения. Постоянное поколение имеет дело с классами, необходимыми для запуска сервера ColdFusion.

Молодое поколение разделено на 3 секции.

Всякий раз, когда выполняется любой код в CFML, объекты создаются и передаются в файл . Во время выполнения запросов эти объекты перемещаются между пространствами выживания (S1 и S0) и пространством Эдема. Неиспользуемые объекты остаются недвижимыми. Эти объекты — используемые и неиспользуемые — контролируются определенным процессом. Этот процесс известен как сборщик мусора. Сборщик мусора пытается удалить эти неиспользуемые объекты, чтобы освободить выделенную память. Иногда эти объекты невозможно собрать. Затем они переходят из молодого поколения в старое поколение. В большинстве случаев эти объекты невозможно передать из-за нескольких ссылок на них в коде приложения. Переменные с общей областью видимости являются яркими примерами объектов, на которые ссылаются во всем коде вашего приложения. Иногда некоторые из этих объектов застревают внутри Старого поколения. Эти объекты собирают и медленно вытягивают все больше и больше памяти из того, что доступно. Это известно как утечка памяти. Утечка памяти может очень негативно сказаться на ваших серверах. Утечка памяти может вызвать:

Если этот сервер используется в коммерческих целях, неожиданное отключение может повредить вашей прибыли. Излишне говорить, что утечка памяти может представлять серьезную угрозу. Итак, как с ними бороться? Есть два основных подхода.

  1. Самый простой способ — запустить инструмент автоматического обнаружения, такой как монитор CF Server, чтобы помочь обнаружить мошеннические процессы памяти. Монитор сервера отлично подходит для пользователей Enterprise Edition. Но как насчет стандартных пользователей? FusionReactor и связанные с ним плагины могут быть жизнеспособным вариантом.
  2. Тогда вам предстоит трудный путь. Если вы испытываете серьезную утечку памяти без каких-либо признаков автоматизации, вам придется вручную проверить код. Этот процесс требует, чтобы вы вручную включали и отключали части кода за раз. При этом вам необходимо наблюдать и принимать к сведению показатели использования памяти. Эти взлеты и падения могут дать вам представление о том, где может скрываться утечка памяти.

Возможно, вам потребуется внести изменения в конфигурацию вашей JVM. Этот процесс управляется через файл jvm.config. Обязательно сделайте первоначальную резервную копию этого файла, прежде чем вносить какие-либо изменения в вашу JVM. Это очень важно, так как это поможет вам вернуть вашу систему в прежнее состояние. После этого откройте файл конфигурации в текстовом процессоре. Найдите строку java.args. Это запись, которая управляет многими вашими функциями конфигурации JVM. Эта строка представляет собой одну длинную строку данных с параметрами, разделенными пробелами, за которыми следует тире. Не забывайте всегда тестировать любые изменения, сделанные на промежуточном сервере, при симулированной нагрузке. Это должно быть сделано как до, так и после развертывания кода.

Настройка сборщика мусора

Одним из самых простых мест для начала оптимизации и настройки является Сборщик мусора. Это может быть так же просто, как переключение между одним из четырех различных вариантов GC.

  • Серийный сборщик мусора
  • Параллельный сборщик мусора
  • Параллельный сборщик мусора Mark Sweep (CMS)
  • Сборщик мусора G1

По умолчанию для ColdFusion используется параллельный сборщик мусора. Приоритетом номер один в этом варианте является производительность. Для этого GC делает второстепенные коллекции параллельно друг другу. Это позволяет более эффективно собирать и со временем может собирать гораздо больше. Приложения со средними и большими наборами данных, работающие на многопроцессорном или многопоточном оборудовании, больше всего выигрывают от этого варианта GC. Однако у этого варианта есть и обратная сторона. Во время сбора мусора ваша система может перестать отвечать на запросы в течение одной секунды или более.

Некоторые приложения CFML считают время отклика более важным, чем общую пропускную способность. Варианты CMS и G1 GC могут быть правильным выбором в этом случае. Эти сборщики, обычно известные как большинство параллельных сборщиков, работают одновременно с вашим приложением. Это сводит к минимуму паузы за счет небольшой нагрузки на ваши приложения. Чтобы переключиться на один из этих вариантов GC, обновите свой java.args, удалив параллельный сборщик и добавив один из наиболее параллельных сборщиков.

Основная цель настройки вашей JVM через GC — сбалансировать максимально доступную свободную кучу при минимизации событий сборки мусора. Идеальная максимальная доступная свободная куча — 30%. Лучший способ сделать это — собрать объекты мусора, пока они еще находятся в «Молодом поколении».

Когда ваше приложение достигнет верхнего предела максимально доступной свободной кучи (70%), вы начнете замечать значительное снижение производительности вашего приложения CF и сервера. Это связано с тем, что выполняется много циклов GC, пытающихся очистить кучу. Производительность резко упадет, поскольку она приостанавливает обработку запросов каждый раз, когда выполняется полный сборщик мусора.

Вы можете проверить GC с помощью журнала GC. Первым шагом является фактическое включение ведения журнала сборщика мусора. При этом используются следующие параметры jvm.args :

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=3 -XX:GCLogFileSize=10240k -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -verbose:gc -Xloggc:convectiveGC.log

После ввода перезапустите сервер. Вы должны увидеть, что новый файл журнала был создан либо в {cf_root}/runtime/bin, либо в {jrun_root}/bin.

Здесь вы можете просмотреть журнал с помощью инструмента анализа журнала GC, такого как GcViewer. Этот инструмент даст вам графическую интерпретацию вашего GC и его деятельности. Используя эти данные, вы можете определить, работает ли ваш ГХ так, как вам нужно.

Существует множество различных областей, которые вы можете точно настроить и настроить для оптимизации серверов и приложений ColdFusion. Давайте посмотрим на некоторые из них.

Настройка постоянного поколения

это замечательный инструмент, который вы также можете использовать для анализа ваших проектов CF. Это может дать вам правильное представление о ваших основных и второстепенных коллекциях. Основные коллекции занимают больше времени, чем второстепенные, что может привести к замедлению работы и даже к сбою серверов. Сокращение количества основных коллекций увеличит пропускную способность. Вот два метода, которые вы можете использовать, чтобы максимизировать производительность.

  • Увеличить XMX
  • Увеличить Xms

Настройка молодого поколения

Когда дело доходит до производительности, штатное поколение берет на себя гораздо более тяжелые потери, чем молодое поколение. Однако для достижения максимальной производительности оба поколения могут быть настроены на оптимальную производительность.

  • -Xmn
  • SurvivorRatio
  • TargetSurvivorRatio

Настройка с помощью UseParallelOldGC

До Java SE6 сбор молодого поколения выполнялся параллельно, в то время как основные коллекции (из поколения Tenured) выполнялись в один поток. Теперь, с Java SE6, вы можете выполнять основные сборы параллельно. Это может фактически улучшить вашу конкретную производительность, вернувшись к старым настройкам. Включите эту функцию, добавив параметр: -XX:+UseParallelOldGC.

Настройка с помощью MaxPermSize

Постоянное поколение используется для хранения объектов класса и объектов метода. Для приложений, использующих множество классов, увеличение размера постоянного поколения значительно увеличило бы пропускную способность.

Настройка с -XX: новое соотношение

Новый параметр отношения — это отношение численности работающего поколения к численности молодого поколения. Профилируя ваше приложение, вы можете настроить это значение соответствующим образом. Это улучшит производительность.

Улучшение коннектора веб-сервера

Правильное подключение и настройка соединителя — ключевая часть подготовки серверов CF к развертыванию. С появлением ColdFusion 2018 появился Инструментарий мониторинга производительности (PMT). PMT на 100 % упрощает настройку разъема. В PMT находится функция автонастройки разъема. Данные о трафике и нагрузке на разъем будут отслеживаться и отображаться в режиме реального времени. Теперь администраторы и разработчики могут войти в систему и визуализировать нагрузку на диаграмме временных рядов для отдельного соединителя.

В настоящее время автотюнер поддерживает 3 основных параметра.

Когда соединитель AJP подключается к серверу ColdFusion, он не закрывает соединение даже после завершения запроса. Он поддерживает соединение активным, поэтому его можно использовать для следующего запроса. Это известно как постоянное соединение.

С помощью автонастройки вы можете установить пороговые значения, когда автонастройка действительно начинается. При пересечении лимитов начинается автонастройка и увеличивается пул соединений. Это удобная функция, которая поможет вам убедиться, что ваш коннектор веб-сервера поддерживает работу с максимальной производительностью.

Итоги по оптимизации и производительности серверов

Помните, что поддержание оптимизации и производительности сервера — это еще не все. Для поддержания максимальной производительности требуется постоянный мониторинг и профилактическое обслуживание. Воспользуйтесь преимуществами инструментов мониторинга и настройки, чтобы убедиться, что вы понимаете, в чем проблема и как ее решить.

Когда вы в последний раз оптимизировали свои серверы? Как вы поддерживаете свой GC и почему?

Присоединяйтесь к революции CF Alive

Узнайте, как мы все можем сделать CF более живым, современным и безопасным в этом году. Присоединяйтесь к другим разработчикам и менеджерам ColdFusion в CF Alive Inner Circle сегодня.

  • Получите ранний доступ к книге и видео CF Alive
  • Станьте частью нового движения за улучшение восприятия CF в мире.
  • Внесите свой вклад в революцию CF Alive
  • Общайтесь с другими разработчиками и менеджерами CF
  • Членство не требует затрат.

Первоначально опубликовано на https://teratech.com 17 мая 2019 г.