К нам в «Ревизиум» часто обращаются владельцы сайтов, у которых возникает проблема с высокой нагрузкой. Ситуация, когда владелец получает от хостера «письмо счастья», являющееся предвестником блокировки сайта, отнюдь не редкая, с ней может столкнуться абсолютно любой владелец сайта или веб-мастер, поэтому мы решили подробно рассмотреть причины возникновения и варианты решения данной проблемы.

Обычно о превышении нагрузки веб-мастера узнают от своих хостеров, которые строго регламентируют и контролируют процесс потребления процессорного времени и на уровне тарифного плана задают ту допустимую нагрузку, которую может создавать аккаунт (обычно она измеряется в % от некоторого разрешенного значения или в CP/процессорных минутах).

Хостер старается равномерно распределить ресурсы процессора среди всех клиентов сервера. Если чей-то аккаунт хостинга будет «съедать» 90% процессорных ресурсов, то остальным достанется только 10%. Поэтому в подобных случаях владельцу аккаунта, превышающего лимиты, придет предупреждение. А при систематических нарушениях аккаунт блокируется, чтобы не мешать работе других сайтов, расположенных на том же сервере. И это, отнюдь, не попытка «развести» клиента на более дорогой тариф, как думают некоторые веб-мастера, поскольку не хостер виноват в том, что сайту с некоторого времени потребовалось больше ресурсов.

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

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

Внешние факторы

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

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

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

Одной из популярных атак, целью которой является получение административного доступа с помощью перебора популярных комбинаций логинов/паролей администратора, является атака вида «брутфорс». Хакерский бот использует специальный словарь с TOP1000 популярных комбинаций (admin/admin, admin/123456,...) и пробует зайти с ними в административную панель сайта. Сам процесс перебора повышает нагрузку, так как на страницу административной панели идут постоянные обращения, причем запросы выполняются ресурсоемким методом POST.

Часто на сайтах используются формы обратной связи или формы регистрации пользователей со слабыми механизмами защиты от ботов. Хорошо, если на форме установлена хоть какая-то «капча» из серии «докажи, что ты не бот». Если сайт попал в базу спаммеров, а «капчи» или другого механизма защиты от «http флуда» нет, то начинается массовая регистрация пользователей со спам-профилями, отправка почты через форму и т.п. Все это создает нагрузку на хостинг, и кроме того, может провоцировать спам-рассылку, за которую хостинг-компания отключает почтовый сервис или блокирует сайт полностью.

Следует отметить, что в настоящий момент все простые защитные механизмы без труда обходятся современными ботами, поэтому необходимо сразу устанавливать что-то серьезное, например, Google Recaptcha2.

Иногда при достаточно большом поисковом индексе (когда в поисковую базу Яндекса и Google попадает большое число страниц), процесс переиндексации может занимать длительное время и создавать большую нагрузку на сервере. Если на вашем сайте всего десяток страниц, вы также можете столкнуться с подобной проблемой, например, если сайт был взломан и на нем размещен дорвей на 50 000 страниц, которые попали в поисковую выдачу. Или поисковый индекс мог заспамить конкурент, который воспользовался ошибками в работе скриптов вашего сайта. Вариантов здесь масса.

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

Часто e-commerce ресурсы используют механизм обмена данными с внешними сервисами. Например, из интернет-магазинов может выгружаться список товарных позиций, в них могут загружаться данные из 1С, у новостных сайтов может происходить регулярный экспорт новостных фидов и пр. Если контент не статический, то каждый такой запрос будет создавать высокую нагрузку на сервер.

Одним из неочевидных моментов, создающих нагрузку, может быть размещение ссылки на сайт или использование изображения с сайта на более посещаемом ресурсе. Один из источника проблемы — это так называемый «хабраэффект», когда сайт не справляется с потоком посетителей с более популярного ресурса. Второй вариант — когда кто-то (или вы сами) разместили на посещаемом блоге (например, в комментариях) картинку со своего сайта, и она загружается у каждого посетителя и создает нагрузку на ваш хостинг. Особенно это может создавать серьезные проблемы в том случае, если картинка генерируется скриптами (например, масштабируется с помощью скриптов timthumb/phpthumb).

Часто сайты, содержашие уязвимости, используются хакерами для проведения атак на другие ресурсы. Иногда для этого злоумышленнику даже не требуется взламывать сайт. Например, с этой проблемой могут столкнуться владельцы не самых свежих версий Wordpress (атака через файл xmlrpc.php). Ваш сайт в данном случае будет выступать промежуточным звеном, а работа скриптов сайта создавать большую нагрузку на сервере.

Если на сайт идет DDOS-атака, то без подключения специальных технических средств, проксирующих трафик (услуга хостинга или сервиса защиты от DDOS), справиться с ней не удастся. Не заметить DDOS достаточно сложно. Из-за того, что на сервер будет создаваться огромная нагрузка, хостер может поступить по-разному: предложить услугу защиты от DDOS, перенести сайт на другой сервере или полностью заблокировать (отключить) сайт. Поэтому для защиты от DDOS желательно иметь заранее заготовленное решение, чтобы при возникновении проблемы оперативно ее решить.

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

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

В результатах анализа следует посмотреть TOP 20 запросов методом POST, TOP 20 запросов методом GET/HEAD, TOP 20 IP адресов по числу хитов, TOP 20 ссылающихся страниц по числу хитов. Все это позволит выявить источник и тип трафика, а также точки входа на сайт или скрипты, которые вызываются чаще всего. Скорее всего они и будут причиной высокой нагрузки.

Для снижения нагрузки при внешних атаках или интенсивных запросах в большинстве случаев достаточно включить защиту от http флуда (например, классический «куки на клиенте + редирект с проверкой») или подключить сайт к сервисам проксирования трафика, которые будут блокировать опасные или особо активные запросы, а хорошие и легитимные — пропускать. Кроме того, статический контент (картинки, скрипты и стили) будут отдаваться не с вашего сайта, а с CDN-серверов, что также существенно снизит нагрузку.

Можно попробовать подключить кэширующий плагин в CMS или кэширующий сервис на хостинге, но в случае внешних факторов, влияющих на нагрузку, это может и не помочь.

Внутренние факторы

Ко внутренним факторам можно отнести все то, что влияет на производительность сайта на уровне скриптов и настроек. То есть то, что поддается контролю со стороны веб-мастера (владельца сайта).

Из-за неграмотно спроектированной архитектуры веб-приложения или неэффективной реализации скриптов неопытными разработчиками возможен случай, когда простое открытие стартовой страницы или отображение результатов поиска на сайте может серьезно нагружать сервер. А рост объема базы данных (например, увеличение числа товарных позиций) с каждым обновлением сайта будет его все больше замедлять, увеличивая нагрузку на хостинг. Отдельные страницы сайта с большим числом информационных блоков могут отправлять по несколько десятков запросов к базе данных, многократно выполнять одни и те же операции с файлами, а иногда даже блокировать работу других элементов сайта. Мы часто сталкиваемся с подобной проблемой у интернет-магазинов, работающих на старой версии Joomla с плагином Virtuemart. В некоторых случаях при открытии страницы каталога выполняется более 100 запросов к базе данных.

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

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

При работе скриптов могут возникать ошибки, которые не отображаются посетителям, но записываются в лог веб-сервера или лог php. Если сайт посещаемый или ошибок много, это также может увеличивать нагрузку на хостинг. Чаще всего ошибки начинают генерироваться в момент переключения сайта на более свежую версию PHP, с которой скрипты не совместимы. Или когда обновляются не все компоненты сайта, и возникают конфликты между новым ядром CMS и старыми версиями плагинов.

Для анализа проблемы высокой нагрузки, вызванной внутренними факторами, требуется выполнить проверку сайта на наличие вредоносного кода (например, проверить сайт бесплатным сканером AI-BOLIT), и, если вредоносного кода не обнаружено, то выполнить профилирование работы скриптов с помощью модулей xhprof или xdebug.

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

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

Продолжительность

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

Если на графике потребления процессорного времени вы видите разовый скачок, то не стоит волноваться. Он практически незаметен, не влияет на доступность сайта и не мешает «соседям» по хостингу. Хуже, если график длительное время ползет вверх или в течение нескольких дней показывает предельную (или превышающую лимит) загрузку процессора. Что делать в этом случае? Необходимо проводить аудит сайтов на аккаунте так, как это было описано выше, проверяя как внешние, так и внутренние факторы, вызывающие проблемы.

Алексей Шишкин
Генеральный директор Redsoft

Мое знакомство с Григорием случилось много лет назад, когда он начал заниматься "лечением" сайтов на Joomla. И эти же сайты были прекрасной иллюстрацией сайтов с проблемами не только в безопасности, но и с производительностью

Лучшим примером был интернет-магазин на решении Virtuemart, меню которого создавало сотни запросов в БД при загрузке одной страницы. Как следствие, сайт тормозил адски, и при увеличении количества категорий, ситуация только ухудшалась. Дело было в программных ошибках этого (самого популярного в Рунете) расширения под Joomla. Похожие проблемы наблюдаются и при работе Битрикса с большими объемами SKU  в каталоге.  И в первом, и во втором случае мы полностью переписывали решения под выбранную платформу. 

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

Лучшим решением проблемы с производительностью является выбор подходящей платформы. Но, к сожалению, этот путь не всегда доступен из-за высокой стоимости на старте работ или при миграции с неоптимальной системы.  Поэтому мы часто сталкиваемся с задачами архитектурной доработки систем. Например, у нас есть сайт на Битриксе, который работает на Mongo вместо MySQL. Это позволило сократить время выдачи контента с 1-2 минут (!) до 1-2 секунд. При этом работы не затронули ядро системы - Битрикс свободно обновляется и "думает", что работает по-прежнему с MySQL.

Виктор Пермяков
Генеральный директор студии Vikiweb

В нашей практике 90% случаев повышенной нагрузки - нагрузка на сервер баз данных.

Возникает нагрузка от неправильной архитектуры, скриптов, которые формируют SQL запросы, большого объема данных.

Обычно если у сайта в БД мало данных и небольшая посещаемость – проблем, собственно, нет, так как даже при неправильной архитектуре и маленьком количестве данных сервер СУБД будет справляться с этим. 

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

• поиск медленных запросов и узких мест, создающих нагрузку;
• оптимизация и сокращение кол-ва SQL запросов к БД;
• изменение архитектуры, если это возможно;
• кеширование данных, использование noSQL решений.

 Общее правило - запросов должно быть как можно меньше и работать они должны как можно быстрее.

Михаил Ушенин
Технический писатель веб-платформы Webasyst

В облаке Webasyst, где размещаются только программные продукты, работающие на основе PHP-фреймворка Webasyst, мы наблюдаем следующие основные причины ухудшения работоспособности сайтов:

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

2. Использование неэффективных настроек программных продуктов. Пример такой настройки — автоматическое формирование миниатюр фотографий товаров «на лету» на витрине интернет-магазина Shop-Script. При небольшой активности на сайте эта настройка иногда может быть полезна; если же у интернет-магазина высокая посещаемость, то иногда это превращается в проблему. Решается она простым перегенерированием всех миниатюр (одной кнопкой) в разделе администрирования интернет-магазина.
   Другой пример неэффективной настройки: отключение кеширования в настройках фреймворка. В ходе выполнения диагностики этот параметр мы проверяем в первую очередь и предлагаем клиенту включить кеширование.

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

Артем Полторанин
Руководитель ReadyScript lab

Внешние факторы (парсеры, простые формы ddos, bruteforce) – являются сегодня серьезными вызовами для разработчиков и владельцев сайтов. Безусловно, повысить порог устойчивости к внешним факторам, вызывающим нагрузку на сервер, сайтам помогает внутренняя оптимизация – это, прежде всего, полноценное использование кеэширования и отсутствие «тяжелых запросов» на самых посещаемых страницах, грамотная организация структуры БД, позволяющая максимально использовать индексы при выборке данных.

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

ReadyScript в своем продукте «Мегамаркет» предлагает готовый инструмент, способный автоматически анализировать и блокировать вредоносные IP, исходя из частотности или вредоносного характера запросов. Такой инструмент позволяет надежно защититься от парсеров и хакеров, обеспечивая круглосуточную доступность интернет-магазина в агрессивной среде.