HighLoad

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

Ситуации бывают разные:

• у кого-то на VPS-сервере с одноядерным процессором на 2000MHz и памятью 128Mb работает простенький корпоративный сайт и справляется с 10 запросами в секунду;

• а у кого-то – собственный физический выделенный сервер с 16-и-ядерным процессором на 4000Mhz и памятью в 40Gb. Стоит на callocation у известного провайдера с четырмя выделенными каналами в 1Gb/s. На нем работает крупный интернет-магазин с огромным функционалом и справляется с 10000 запросов в секунду.

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

Признаки, того, что начинается highload:

медленная загрузка сайта;

неполная загрузка контента страниц (оборванная страница, недогруженные картинки);

появление различных ошибок в зависимости от времени;

обрыв соединения с сервером.

Чем же грозит вовремя неустраненная проблема в инфраструктуре?

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

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

Оптимизация

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

Какие основные действия предпринимают специалисты компании Линкол для решения проблемы:

• Нагрузочное тестирование проекта.

• Аудит и доработка исходного кода проекта (CMS, фреймворки, самописные движки и модули).

• Проверка и защита от уязвимостей. Защита от DDoS.

• Аудит, настройка и установка софта сервера (тонкая настройка ОС и системного ПО, развертывание обновлений).

• Аудит и подбор железа сервера (кластеризация и другие архитектурные решения, подбор дата-центра и поставщиков оборудования).

• Настройка кэширования (на уровне клиента, прокси-сервера и CMS, фреймворка).

• Оптимизация СУБД (мониторинг и исправление тяжелых запросов, применение Memcached, MySQL, PostgreSQL или NoSQL).

• Виртуализация (изоляция логических модулей проекта в отдельные контейнеры).

• Масштабирование (клонирование существующего проекта на новый сервер и настройка репликации данных).

• Балансировка (распределение трафика между серверами на уровне DNS, nginx и т. д.).

В 90% случаев

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

Вот основные ошибки разработки, влияющие на быстродействие проекта:

• использование «тяжелых» CMS или неподходящего фреймворка;

• использование популярных CMS без корректной настройки;

• подключение непроверенных сторонних модулей;

• ошибки в программировании:

  • неоптимальные алгоритмы;

  • множество запросов или тяжелые запросы к БД;

  • «дыры» в безопасности.

• отсутствие кэширования;

• выбор несоответствующего хостинга под проект.

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