Цель этой статьи — продемонстрировать, как улучшить существующие приложения ColdFusion и, что еще лучше, спроектировать и построить их так, чтобы они безупречно масштабировались с первого дня. Все в этой статье основано на 14-летней работе с приложением 3D ColdFusion. 3D; проектирование, разработка и развертывание приложений.
В 1996 году я начал работать с ColdFusion в качестве бизнес-менеджера, нуждающегося в решении. Это говорит о главной силе, которая подтолкнула ColdFusion стать основным языком Интернета; его возможности быстрой разработки приложений (RAD); во многом благодаря своей простоте использования. Я не был разработчиком и, несмотря на это, ColdFusion позволил мне создать крупнейший веб-портал для деталей для дизельных двигателей и генераторов Power Bank International.
В один момент мы получали 10 000 просмотров в день, что в 1997 году было очень много для нишевого рынка, и это подводит меня к одному из основных пунктов этой статьи. Теперь, спустя 14 лет, я провожу большую часть своего времени, помогая многим клиентам устранять неполадки в существующих приложениях и повышать производительность. Иногда я получаю возможность помочь клиентам понять это с самого начала; Эта последняя работа — лучшая из всех миров.
Миф о ColdFusion
Существует точка зрения, согласно которой ColdFusion не работает оптимально и не будет хорошо масштабироваться. Как я упоминал во введении выше, я использую ColdFusion начиная с версии 1.54 в 1996 году. Кроме того, я провел последние 11 лет, помогая клиентам повысить производительность и создавать приложения ColdFusion с нуля. За это время я работал с каждой версией ColdFusion, некоторые не были хорошими; 4 и 6, в частности, но большинство из них были заполнены новыми удивительными парадигмами разработки, пользовательскими тегами, пользовательскими тегами, CFC и т. Д. За этот длительный период работы с ColdFusion сам ColdFusion редко вызывал какие-либо серьезные проблемы, фактически большую часть времени проблемы были вызваны уровнем данных и взаимодействием ColdFusion с уровнем данных.
Как / где работает ColdFusion?
Начиная с версии MX 6-6.1 ColdFusion является сервером приложений Java J2EE-JavaEE. J2EE-JavaEE — признанные стандарты для разных продуктов; Resin, TomCat, WebSphere, WebLogic и т. Д. Все это требует виртуальной машины Java или JVM и контейнера сервлетов в качестве основных компонентов. В случае ColdFusion JRun является контейнером сервлетов по умолчанию с Sun JVM. Однако одной из сильных сторон ColdFusion является то, что он может работать на любой JVM в любом контейнере сервлетов и во всех известных операционных системах. Чтобы получить представление о ColdFusion и его месте в общей инфраструктуре, вот диаграмма, показывающая, где находится ColdFusion:
Если бы это была установка с несколькими экземплярами, было бы несколько «Сервер приложений Java <COLDFUSION>». Это важная деталь, о которой нужно знать, потому что одной из изнурительных проблем для приложений Java, таких как ColdFusion, являются проблемы «нехватки памяти». JVM имеет «кучу» памяти, которая, в свою очередь, поступает из общей оперативной памяти операционной системы, иногда при «обмене» распределением и использованием между кучей JVM и системной оперативной памятью возникают проблемы. Лучший совет, который у меня есть, — везде, где это возможно, использовать 64-битные системы, а если у вас 32-битные, то по крайней мере 4 ГБ общего ОЗУ. Еще раз, это поведение, которое проявится как очевидные проблемы ColdFusion; не является.
Существующие проблемы — лучший подход
Как и в любой другой компьютерной парадигме, ColdFusion обрабатывает и манипулирует данными, иногда создавая данные в этом процессе. Эти данные должны поступать из веб-браузера или другого источника на сервер веб-приложений, часто взаимодействуя с внутренними системами; в основном базы данных, а затем обратно в веб-браузер или другую точку излучения. Это называется циклом запроса / ответа. Если у нас есть медленное / неотвечающее приложение для устранения неполадок, знание того, где находится замедление, всегда имеет решающее значение. В большинстве случаев ответственность за это лежит на ColdFusion, и, как уже говорилось, в большинстве случаев это не является реальной причиной проблемы. Нам необходимо рассмотреть каждую часть инфраструктуры, чтобы точно определить реальную проблему. Еще один важный момент, ColdFusion делает невероятную работу по регистрации элементов. В частности, * {instance} -out.журнал, который находится в одном из двух мест:
Standard non multiple instance install
{drive}\{coldfusion root}\runtime\logs
Multiple instance install
{drive}\JRun4\logs
Этот журнал, где * {instance} — это фактическое имя сервера / экземпляра ColdFusion, — это обширная информация о том, что происходит внутри ColdFusion, а также основные точки зависимости. Всегда проверяйте этот журнал регулярно.
Другим действительно хорошим советом для устранения существующих проблем является включение «расширенной / регистрации метрик». Я всегда рекомендую включить это и оставить его включенным, накладные расходы незначительны и окупаемость жизненно важной информации огромна. Это покажет состояние потоков и памяти в любой установленный вами временной интервал. Вот как, найти файл jrun.xml в одном из этих двух мест …
Standard non multiple instance install
{drive}\{coldfusion root}\runtime\servers\SERVER-INF
Multiple instance install
{drive}\JRun4\servers\SERVER-INF
В файле jrun.xml найдите слово «метрики». Первое появление будет в этом разделе около 1/3 пути через файл.
<!-- This Service provides metrics information -->
<!-- ================================================================== -->
<service class="coldfusion.server.jrun4.metrics.MetricsServiceAdapter" name="MetricsService">
<attribute name="bindToJNDI">true</attribute>
</service>
Убедитесь, что этот раздел не закомментирован.
Следующий раздел, требующий изменения, находится немного дальше по файлу, и здесь мы меняем значение «false» на «true» …
<service class="jrunx.metrics.MetricsService" name="MetricsService">
<attribute name="bindToJNDI">true</attribute>
</service>
Наконец, мы добавим расширенное ведение журналов, чтобы выделить отдельный журнал для самих показателей, добавим значение «- {log.level}»…
<service class="jrunx.logger.FileLogEventHandler" name="FileLogEventHandler">
<attribute name="filename">{jrun.rootdir}/logs/{jrun.server.name}-{log.level}.log</attribute>
Ведение журнала метрик является очень мощным средством, позволяющим нам просматривать поведение потоков и памяти в течение определенного периода времени как в отдельном журнале, так и в {instance} -out.log, который является важной информацией при возникновении проблем, помогая точно определять тенденции, такие как утечки памяти , Использование монитора сервера также полезно, я предпочитаю один из двух сторонних продуктов, FusionReactor или SeeFusion, у ColdFusion также есть один, но он может вызвать проблемы при неправильном использовании.
В качестве последнего замечания по решению существующих проблем важно рассмотреть нагрузочное тестирование в тестовой среде, чтобы воспроизвести производственные проблемы. Мы поговорим об этом более подробно в следующем разделе.
Правильно с первого дня
Существует надежный способ создания приложений ColdFusion, если выполняются следующие шаги. Мы называем это «Жизненный цикл приложения», и вот подробности…
Шаг 1: Потребности пользователя — Каркас / Прототип
Захватите все потребности пользователей перед тем, как начинать кодировать, и заставьте их подписать тот факт, что вы захватили то, что им нужно. Кроме того, в идеале, дайте им адекватный механизм обратной связи, который является динамичным. Как я упоминал выше, Хэл Хелмс создал в ColdFusion конструкцию под названием «DevNotes», которая в сочетании с WireFrame представляет собой очень эффективный способ сбора отзывов от пользователей перед началом кодирования.
На этом этапе сбора основной функциональности мы используем два основных «подэтапа». Во-первых, это создание «каркасного» кликабельного без графики, я подчеркиваю это, потому что некоторые фирмы называют фазу внешнего вида (прототип) фазой «каркас», по нашему мнению, каркас не должен иметь графику, но должен быть реалистичная модель с переходами по ссылкам. После того, как клиент одобрил модель с возможностью нажатия, мы можем добавить графику для создания прототипа.
Как только клиент одобрил прототип, мы переходим к этапу разработки.
Шаг 2: Разработка / модульное тестирование
В нашем магазине мы разрабатываем локально, и у каждого разработчика есть версия ColdFusion для разработчиков и любые другие копии того, что им может понадобиться, например, база данных. Суть в том, что каждый разработчик независим и может функционировать независимо от того, где он находится; мы фанатичны в отношении дистанционного общения как по стилю жизни разработчиков, так и по экологическим причинам. Никакой код не может быть помечен для перехода к интеграционному тестированию, пока все модульные тесты не завершатся успешно, и мы говорим не просто о модульных тестах, как в конструкциях OO-CFC, мы подразумеваем все функции кода без нарушения работы локальной системы разработчика.
Шаг 3: Тестирование разработки / интеграции
Здесь мы берем код от всех разработчиков и переносим его на центральный сервер разработки и тестируем все приложение, чтобы убедиться, что код одного разработчика не нарушает код другого. Если какой-либо код ломается, он отправляется обратно исходному разработчику для исправления, и эта итерация продолжается до тех пор, пока весь код в среде Integration Testing не заработает без сбоев, после чего он будет перемещен в QA-Load Testing.
Шаг 4: QA-нагрузочное тестирование
Это наиболее часто пропускаемая фаза разработки приложений, и она никогда не должна быть упущена; на самом деле почти все клиенты, которым мы помогли в нашей практике устранения неполадок, имеют проблемы, потому что они не тестировали приложение. Мы советуем и практикуем нагрузочное тестирование, по крайней мере, до 150% от ожидаемой нагрузки, а также заставляем клиента указать минимальное допустимое время отклика страницы. Приложение не следует перемещать в рабочее состояние до тех пор, пока оно не пройдет все нагрузочные испытания, что означает, что оно отвечает на требуемое время ответа клиентской страницы при 150% ожидаемой максимальной нагрузки. Код снова повторяется для разработчиков и возвращается через модульное тестирование, интеграционное тестирование и нагрузочное тестирование.
Шаг 5: Производство
Выполнив первые 4 шага жизненного цикла приложения и только после того, как они пройдены, мы теперь готовы развернуть приложение в Production. Иногда существует разделение между нагрузочным тестированием и QA, когда среда QA является прямой копией реального производства, это дополнительный шаг, который не нужен, но приятно иметь.
Советы по производительности кода ColdFusion
Если соблюдаются все пункты предыдущего раздела, все проблемы с ColdFusion, связанные с кодом, будут обнаружены перед началом работы. Есть два других указателя, которые я могу дать, чтобы помочь в базовой производительности ColdFusion.
- Обновление до ColdFusion 9 (при этом значительно повышается производительность.
- Обратитесь к этой статье от Adobe, чтобы узнать, как оптимизировать кодирование в ColdFusion.
Вывод
ColdFusion — это хорошо масштабируемый, хорошо работающий язык. С точки зрения разработчика, язык разметки ColdFusion (cfml) — очень приятный язык для работы со всеми видами расширяемости. С точки зрения управления расширяемость ColdFusion делает его очень экономически выгодным вариантом, а его способность работать в Unix, Windows и Osx обеспечивает безграничную гибкость.
Ключевые моменты для запоминания
- Создавайте расширенные / метрические журналы и регулярно просматривайте полученные журналы.
- Следуя жизненному циклу приложения, ни один код не достигнет производства, что может вызвать проблемы.
- Определение ресурсов, фактически необходимых для поддержки вашего приложения, с помощью итеративного нагрузочного тестирования также обеспечит масштабируемость и производительность.
- Оптимальной средой для приложений ColdFusion является ColdFusion 9 на 64-битных системах.