Проблема производительности может никогда не возникнуть перед компанией, если нагрузка на ее сайт измеряется десятками посетителей в сутки, а про сам сайт вполне уместно говорить «лишь бы работало». Однако для корпоративных и профессиональных порталов крупных компаний деградация производительности оборачивается прямыми потерями. Сюда же можно отнести и «странички» небольших фирм, профиль деятельности которых тесно связан с Интернетом: интернет-магазины, новостные сайты, поисковые системы и проекты Web 2.0, у обычных пользователей часто ассоциирующиеся с социальными сетями. Разделение между этими тремя группами весьма условно, тем не менее большинство организаций сегодня осознают важность наличия хорошего сайта: если, например, интернет-магазин не выдержит наплыва пользователей, он понесет прямые финансовые потери, а какая-либо консалтинговая компания в этой ситуации понесет репутационный ущерб. Кроме того, не стоит забывать, что помимо внешних порталов многие компании интенсивно используют внутренние корпоративные порталы, нагрузка на которые может быть даже выше, чем на сайт интернет-магазина.
Факторы риска
Благополучие портала зависит от хостинга, платформы и настройки, а также от качества разработки.
Понятие хостинг в данном случае включает в себя всю совокупность услуг, предоставляемых провайдером: конфигурирование серверов, поддержка производительности канала, базы данных и др. Проблемы производительности, связанные с хостингом, относятся к числу наиболее трудно определяемых, поскольку для обычного тестирования понадобится, как минимум, еще один провайдер. Как показывает наш опыт, только устранение банальных ошибок конфигурирования сервера позволяет на порядок увеличить производительность.
Платформа – это, пожалуй, самый предсказуемый компонент, что, однако, не означает простоту выбора или легкость оптимизации. Однако при грамотном подходе можно рассчитывать на вполне приличные и, самое главное, в большой степени прогнозируемые результаты. Настройки, безусловно, крайне важны, но можно использовать рекомендованные.
Наибольшее внимание сегодня сосредоточено на порталах, построенных на основе PHP – лидирующего языка создания динамических сайтов. Для порталов на платформе PHP особое внимание должно быть уделено скорости работы с PHP-кодом: по нашим данным, до 60% рабочего времени Web-серверы тратят на повторную компиляцию PHP-кода перед исполнением. В таких условиях, очевидно, следует использовать PHP-прекомпиляторы (ускорители), принцип действия которых основан на кэшировании низкоуровневого псевдокода интерпретатора PHP. Кстати, эту проблему можно отнести и к компетенции провайдеров, ведь именно они определяют состав программного обеспечения. Кроме того, скорость выполнения PHP-приложений очень сильно зависит от загруженности файловой системы. К примеру, если выставить большое время хранения сессий, количество файлов может быстро достичь миллионов.
Еще до начала претворения проекта в жизнь важно понять, насколько интенсивно будет использоваться база данных. Иногда возможностей MySQL оказывается недостаточно, и лучше будет остановиться на Oracle Database или Microsoft SQL Server. Здесь важно помнить, что деградация производительности портала возникает часто именно из-за неаккуратной работы с базой данных: от того, как составлен запрос, время подготовки выборки может отличаться на порядки. На общую скорость влияет еще и количество запросов к базе данных; например, по сведениям компании NetStream, при генерации страницы сложного сайта может быть 20-50 обращений к базе данных. Но по нашим наблюдениям, в некоторых проектах только меню сайта может выполнять до 5 тыс. запросов к базе данных, что однозначно указывает на недостатки разработки. Меню просто не должно быть таким сложным и «тяжелым», и, даже если все запросы сами по себе корректны и просты, большое их количество приведет к запредельной нагрузке на базу данных.
Недостаточная квалификация Web-мастеров и невнимание к внутреннему устройству порталов сильно обостряют сегодня проблему разработки. Действительно, заказчик, а как следствие и разработчик прежде всего обращают внимание на интерфейс (строгое соответствие цветов корпоративному стилю, красивые анимационные ролики, удобство работы), но не на производительность, тем более что ее реальное значение замерить довольно сложно.
Решение проблемы производительности
Некоторые разработчики систем управления контентом сайта (Content Management System, CMS) предлагают сертифицировать хостинг-провайдеров, эту идею поддерживают потребители, но не сами хостеры, хотя подобная практика сегодня уже широко распространена (сертификация имеется у NetCat, Amiro.CMS, «1С-Битрикс» и др.). Однако вряд ли сертификация поможет хостерам привлекать клиентов, несмотря на то, что, безусловно, сертифицированный провайдер имеет некоторое преимущество – в некотором смысле сертификация и матрицы совместимости решений, хостеров и тарифов ограничивают выбор потребителей, хотя и уберегают от проблем несовместимости. Конечно, Web-мастер сам может произвести оценку соответствия требований CMS возможностям хостера. Но при отсутствии сертификата все сопутствующие риски потребитель берет на себя.
В процессе сертификации определяется возможность платформ штатно функционировать на площадке хостера, но далеко не все хостеры совместимы со всеми CMS. Некоторые поставщики CMS-решений публикуют списки провайдеров, на хостинге которых их решение не работает либо работает с замедлением. Поэтому при выборе платформы для разработки необходимо определять связку CMS и хостинг-провайдер. Однако сертификационные испытания обычно проводятся в заведомо выигрышных условиях, отличающихся от реальных, а приобретая виртуальный хостинг, компания не застрахована от того, что вместе с ней сервер будут использовать еще несколько сотен клиентов.
Стоит упомянуть и еще один аспект, тесно связанный с сертификацией услуг хостинга. Речь идет о разработке хостерами специальных тарифных планов, оптимизированных под конкретное CMS-решение. В большинстве случаев такой тариф предлагает совокупность стандартных услуг с гарантированными выгодными условиями применения CMS. Нередко подобные предложения оказываются скорее маркетинговыми акциями, поскольку реально тариф мало отличается от стандартных, но в некоторых случаях действительно производится всестороннее тестирование и оптимизация под конкретный CMS-продукт. В качестве примера заботы о пользователях и тесной интеграции с CMS можно привести хостинг-провайдера .masterhost, который предлагает целую линейку «профессиональных» тарифов, нацеленных на использование с различными CMS-продуктами. Так, тариф «CMS-профи» по состоянию на конец января 2010 года ориентирован на «1С-Битрикс», Drupal, WordPress, Joomla, PHPShop, Amiro.CMS FREE и NetCat. Однако наилучшим вариантом с точки зрения обеспечения нужной производительности является использование собственного выделенного сервера, что дает большую гибкость в настройке, в том числе и по части оптимизации производительности, нежели виртуальный хостинг. Однако, если Web-мастер не готов к такой работе, лучше выбирать «коробочный» преднастроенный хостинг.
В общем случае в ответ на запрос пользователя на стороне сервера происходит обращение к базе данных, далее свою работу выполняет PHP-код, а затем сформированная страница доставляется пользователю. Кроме того, здесь присутствует еще процесс загрузки статических элементов страницы. В высоконагруженных системах с большим количеством посетителей этот процесс выполняется отдельным сервером (двухуровневая архитектура Web-сервера), при этом затраты на выделение дополнительного узла с лихвой покрываются возросшей надежностью и предсказуемостью работы серверов. Однако в тех случаях, когда статическую обработку основной Web-сервер отдает на откуп Apache, создается неприятная ситуация, сопровождающаяся практически бесконтрольным ростом расхода памяти. Это связано с тем, что Apache загружает ненужные модули и использует большое количество дочерних процессов.
Оптимизировать работу PHP и обращение к базе данных помогают инструменты отладки, присутствующие во всех серьезных CMS. Прежде всего необходимо обратить внимание на такие характеристики, как общее время создания страницы, а также время обращения к базе данных (время выполнения запросов). Хорошо, если имеется возможность увидеть подробную информацию по запросам к базе данных, выяснить, какой запрос занимает наибольшее время и почему. Грамотно составленный «вручную» запрос часто выполняется быстрее, чем построенный конструктором базы данных. Впрочем, известны и обратные случаи. Полезно также использовать механизм кэширования запросов, которые не требуется выполнять при каждом показе страницы.
Следующий этап – оптимизация работы PHP. Сегодня все более популярным становится Alternative PHP Cache. По-прежнему сильны позиции eAccelerator, а также Zend. Как показывает практика, скорость создания страницы вырастает в несколько раз при использовании таких акселераторов, и при выборе хостинга надо обращать внимание на их наличие, а на собственном сервере ставить их в обязательном порядке.
Говоря о качестве разработки, следует учитывать особенности использования готовых API, предоставляемых разработчикам CMS-систем. Специалисты нашей компании довольно скептически относятся к стандартным API – разработчик, применяя стандартный интерфейс, должен понимать механизм его работы. К сожалению, для многих Web-мастеров API так и остаются непознанными.
Говоря о производительности сайтов, нельзя не упомянуть о масштабируемости. Даже если сайт построен грамотно, может возникнуть ситуация, когда его быстродействия будет недостаточно, например в случае временного наплыва большого количества посетителей или увеличения общей популярности ресурса. Всегда надо помнить, что вопросам масштабирования высоконагруженных сайтов надо уделять пристальное внимание. Более того, подобные проекты должны быть масштабируемы в любом из возможных узких мест.
***
Проблема быстродействия сайтов сегодня стоит довольно остро, причем большинство Web-мастеров пока не принимают ее во внимание, концентрируясь на функциональности или интерфейсе. Для измерения этого параметра применяется ряд инструментов, которые кроме количественной оценки позволяют определить узкие места конфигурации, однако для создания хороших быстрых сайтов прежде всего требуются разработчики, осознающие важность этой проблемы.
Сергей Рыжиков (rsv@1c-bitrix.ru) – генеральный директор компании «1С-Битрикс» (Москва).
Монитор производительности
Компания «1С-Битрикс» включила в линейку своих продуктов модуль «Монитор производительности», позволяющий проводить комплексный анализ работы портала и выявлять недочеты, сказывающиеся на его быстродействии.
В модуле можно запустить пятиминутное тестирование проекта, в ходе которого будет произведен анализ всех параметров, влияющих на быстродействие сайта, включая характеристики хостинга, собственные настройки «1С-Битрикс», а также особенности разработки. Кроме того, модуль выполняет сравнение с эталонной конфигурацией, развернутой на виртуальной машине. Необходимо, правда, отметить, что оценку быстродействия «Монитор производительности» осуществляет на естественной нагрузке, что не совсем удобно.
