Рубрики
Наследие

Хайлоад: Типичные ошибки клиентов

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

Мода важнее здравого смысла

Процитирую диалог с одним из клиентов:

— Сколько стоит поставить nginx?
— Зависит от задачи, а в чем она состоит?
— У меня сайт медленно работает, и я слышал, что nginx позволяет его ускорить!
— Я вижу по анализатору, что на сайте более 200 изображений, а нагрузка на сервер при этом 2-3%. Проблема не в сервере, а в том, что слишком много изображений, на погрузку которых браузер тратит свои ресурсы.
— А разве nginx не ускорит их отдачу?
— Ускорит, но проблема не в скорости их загрузки, а в большом числе.
— Что же делать?
— Переписать дизайн, и вынести картинки подгрузкой в css.
— Это слишком долго, я хочу nginx и готов заплатить.
— Хорошо, но предупреждаю — это не сильно повлияет на скорость загрузки сайта.

В результате, после установки nginx, клиент был вынужден обратиться к услугам профессионального верстальщика, который сократил его 200+ изображений до 83-х, вынеся все повторяющиеся элементы в css.
Его проблема была не в том, что он не понимал как пагубно влияет такое число изображений на скорость открытия страницы, а безумное следование моды: медленно работает — ставь nginx!

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

Мода важнее здравого смысла

Процитирую диалог с одним из клиентов:

— Сколько стоит поставить nginx?
— Зависит от задачи, а в чем она состоит?
— У меня сайт медленно работает, и я слышал, что nginx позволяет его ускорить!
— Я вижу по анализатору, что на сайте более 200 изображений, а нагрузка на сервер при этом 2-3%. Проблема не в сервере, а в том, что слишком много изображений, на погрузку которых браузер тратит свои ресурсы.
— А разве nginx не ускорит их отдачу?
— Ускорит, но проблема не в скорости их загрузки, а в большом числе.
— Что же делать?
— Переписать дизайн, и вынести картинки подгрузкой в css.
— Это слишком долго, я хочу nginx и готов заплатить.
— Хорошо, но предупреждаю — это не сильно повлияет на скорость загрузки сайта.

В результате, после установки nginx, клиент был вынужден обратиться к услугам профессионального верстальщика, который сократил его 200+ изображений до 83-х, вынеся все повторяющиеся элементы в css.
Его проблема была не в том, что он не понимал как пагубно влияет такое число изображений на скорость открытия страницы, а безумное следование моды: медленно работает — ставь nginx!

Гадание вместо статистики

Процитирую диалог с одним из клиентов:

— Мне надо настроить MySQL!
— А что с ним такое?
— У меня клиенты на хостинге жалуются, что их сайты тормозят!
— Но я вижу, что mysql потребляет 2-5% RAM и 15-20% CPU. И нагрузки никакой нет, все запросы успешно попадают в кеш.
— Тогда надо поставить xcache для php, выдав ему больше памяти, потому что скорость открытия сайтов ну очень низкая!
— Я могу поставить, только не гарантирую, что это поможет.
— А что же делать?
— Заказать у меня аудит сервера, по результатам которого работать над найденными проблемами.
— Хорошо, заказываю.

По результатам анализа, проблема оказалась в медленном выполнении кода SAPE, причиной которого стала медленная работа DNS ресловеров, предоставленных Дата-Центром: из 3-х работал только один, да и то с большими задержками.
Проблема решилась прописыванием DNS ресловера Goole 8.8.8.8 и 8.8.4.4

Наличие практического опыта без фундаментальных знаний

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

— Мне нужен аудит двух серверов, почему на одном сервере InnoDB работает правильно, а на другом — нет.
— А что значит правильно? Задачи у серверов одинаковые?
— На одном сервере после переноса базы в InnoDB, сайт стал открываться быстрее. А на другом сервере — нет.
— Хорошо, разберусь.

На одном сервере сайт был на CMS Drupal, который умеет использовать InnoDB и имеет собственные схемы кеширования. Проблем никаких не возникало.
На другом сервере сайт был на CMS DLE, в запросах постоянно был select count с последующими множеством update. Так как CMS была лицензионная, примеры таких запросов были отправлены разработчику, который рекомендовал отключить счетчики страниц. После чего проблема пропала.
Провести сравнение запросов на серверах клиенту и в голову не приходило, он занимался тем, что постоянно менял параметры в конфиге mysql, в надежде, что станет быстрее работать.

Неумение разделять задачи

Один очень крупный заказчик, занимающийся стримингом и имеющий сайт, входящий в top-3 одной из узких ниш, пожаловался, что возникла проблема с конвертацией видео.
Сервер, который занимался конвертацией был очень мощный, но уже не смог обрабатывать все поступающие видео от пользователей с должной скоростью.
Мне нужно было произвести анализ, какой сервер лучше выбрать из ряда предложений дата-центра.
Как оказалось, конветрация более всего использовала ресурсы процессора и диска, в меньшей степени — оперативной памяти, которая пустовала на 90%.
Я предложил ему вместо перехода на новый сервер, взять 4-е более слабые модели, которые по цене выходили дешевле.

— Нет, мне это не подойдет. Я буду конвертировать 4-е разных файла от пользователей, но конвертация все равно будет медленной, я уже это пробовал! Мне нужно один, но быстро!
— Так я для этого и советую взять 4-е сервера. Разделить видео на 4-е части, затем каждую часть сконвертировать на своем сервере. После чего склеить.
— А разве так можно?!
— Нужно.

Разумеется, что конвертация прошла очень быстро, но главное — теперь клиент четко знает, сколько именно ему нужно докупить серверов, для того, чтоб скорость конвертации оставалась на должном уровне.

Отсутствие кеширования


— У меня большая нагрузка на MySQL. Посоветовали memcache! Я поставил — не помогло!
— В смысле — поставил?
— Ну сделал apt-get install memcached php5-memcache и рестартовал апач.
— И все?
— Да! А разве еще что-то надо?

Множество людей тратит невероятно большие деньги на покупку мощных серверов. И все это из-за недостаточности понимания того, что же такое на самом деле является кеширование.
В качестве примера, я приведу решение проблемы на биржевой системе.
Сервера постоянно получают информацию по стоимости акций, клиенты просматривают графики, покупают-продают, вобщем как обычно.
При этом используется черезвычайно мощный сервер и программисты уверяют, что действительно оптимизировали все что могли, и проблема в недостатке железа. Но владелец проекта приводит другую статистику — с ростом каждой тысячи активных пользователей приходится брать вдвое мощный сервер. Сейчас их 4000 и если рост будет идти также быстро как и сейчас, то в скором времени придется переезжать на суперкомпьютер.
Аудит шел достаточно долго — на первый взгляд действительно, все было кешировано:

  • повторяющиеся запросы складывались в memcache
  • был установлен и настроен xcache, который хранил все php скрипты в оперативной памяти
  • все статичные файлы выдавались с правильным заголовком expired

А затем я нашел директорию, в которой были сотни тысяч файлов. На ее открытие уходило несколько секунд.
Дословно процитирую диалог:
— Это графики пользователей, которые они хотят получать. Там можно накладывать несколько графиков в один. У каждого пользователя — свои графики.
— А сколько всего акций и сколько всего пользователей?
— Примерно 400 акций и около 60000 пользователей.
— А если выдавать графики для каждой акции, а потом просто склеивать картинки в одну общую?
— Уже так думали делать, но будет большая нагрузка на диск — их все равно придется записывать перед отдачей.
— А зачем? Пусть они собираются на стороне клиента.
— Но как???
— При помощи javascript.
— Склеивать картинки через javascript на стороне клиента?
— Нет. Выдавать цифры, с помощью которых ajax будет рисовать графики, а цифры отдавать через push с помощью…
— Спасибо, уже не надо продолжать, поняли свою ошибку.
Кеширование — это не просто сохранение картинок на диске, это немного нечто большее…

Попытка масштабировать без понимания сути проблемы


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

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

Наличие единой точки отказа

Компания, поставлявшая услуги хостинга картинок, решила подумать о защите от DDOS атак. Не смотря на многочисленные доводы о том, что лучшая защита от DDOS — это кластер грамотно настроенных серверов с фильтрацией, технический директор компании решил использовать Cisco RiverGuard для защиты.
Шло время, одного сервера стало недостаточно, и незаметно их число возросло до шестидесяти. Сервера закупались, ставились в стойки, но весь трафик продолжал идти через циску.
А потом наступила проблема — трафик перестал расти. Раньше, с ростом числа серверов трафик рос пропорционально, но сейчас перестал.
Я снял статистику с циски по snmp и убедился, что эта железка испытывает явные проблемы с перегрузками. Техдиректор сразу решил, что началась DDOS атака.
Однако по анализу логов все было чисто. Проблема была явно в перегрузке точки, через которую шел трафик.
Тем не менее, владельца бизнеса это не убедило, так как технический директор мотивировал тем, что «Cisco — это сила, а частный консультант — это обычный человек».
Проблема продолжалась в течении года, пока наконец под моими многочисленными уговорами, технический директор не отправил кейс с графиками загрузки.
Ответ пришел достаточно быстро, в котором однозначно указывалось, что этот девайс перестанет нормально работать, если число одновременных запросов будет выше 70k.
После этого владелец наконец рискнул убрать Guard с канала, напрямую дав его на все стойки. Разумеется, трафик начал расти.
Однако тот, кто прочитав, подумает, что единая точка отказа это Cisco RiverGuard, тот ошибется. Разумеется, единой точной отказа был технический директор.

Белогривые лошадки

У нас есть игра для социальной сети Вконтакте. Мы хотим сделать версию для Facebook, но боимся, что сервер не выдержит. По этому мы перешли на облако, а кластер для нас это слишком дорого для начала. Но потом, когда мы заработаем, то обязательно перейдем на кластер.
Когда у вас появляется кластер, то вы все равно будете иметь некий лимит ресурсов, определяемый числом серверов в кластере.
Облако напротив — дает мифическую свободу ресурсов, позволяя на какой-то момент не задумываться, а просто оплачивать перерасход ресурсов, в надежде, что прибыль окупит затраты.
Коварство заключается в том, что рост нагрузки не связан линейно с ростом посещаемости и целиком зависит от радиуса кривизны приложения. Наверное каждый слышал притчу о награде изобретателя шахмат?
На первую клетку шахматной доски — одно зернышко, на второе — два, и так далее.
Так и с облаками. На первую тысячу посетителей — один слот, на вторую — два, на третью — четыре. А вот когда их становится пять, то внезапно(!) приходит озарение, что следующую тысячу «мы не потянем», полученных денег едва хватает чтоб оплатить за облако, а на оптимизацию кривого движка игры уже совсем ничего не осталось.

Заключение

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *