5 уроков для разработчиков высоконагруженных систем

[2r2w]

мне кажется, или эта статья — пиар-акция вашей компании?

[Pyrus]

Вы так говорите, как будто это что-то плохое.

А если серьезно — нам нравится делать полезные вещи. Кому-то наша система приносит пользу, а кто-то, мы надеемся, извлечет пользу из этого текста.

[2r2w]

я ничего против не имею ни против вас, ни против того что вы делаете. Просто прочитав, я понял, что вы — клевые(наверное, так и есть), но ничего нового не узнал — вот, что я имел ввиду, что разделу статья не очень соответствует. ее б лучше в «я пиарюсь»

[voidMan]

Не увидел пиара конкретного продукта, увидел общие приёмы (уроки) проектирования и цикла разработки на примере собственного продукта. Вполне соотстветствует тематике хабов, мне кажется

[Vas3K]

6. Желтый снег есть нельзя. Обязательно добавьте, это важный урок.

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

Кто-нибудь читая этот комментарий вспомнит какой был урок №2 не отматывая вверх? То-то же.

[Pyrus]

Спасибо за комментарий. Как вы, наверное, заметили, это пост с пометкой «из песочницы». Т.е. он у нас тут первый. Будем пробовать писать истории в другом формате.

[vp_arth]

Какой был урок №2 и правда не могу, зато могу перечислить все пять не по порядку…
Хотя безусловно вы правы, суховато…

[vp_arth]

мы приняли непопулярное решение: написать свою

Для высоконагруженного приложения — это самое популярное решение.
Там, где идет борьба за миллисекунды нет места библиотекам общего назначения…

[mark_ablov]

> Запускать профайлер на боевом сервере практически невозможно – он добавляет слишком много накладных расходов и сервис начинает тормозить
A/B подход?

[andrey239]

> Запускать профайлер на боевом сервере практически невозможно – он добавляет слишком много накладных расходов и сервис начинает тормозить

Что-то тут не так. Мы примерно о каких технологиях говорим? apache? tomcat? php?

Профайлеры бывают разные и способы профилирования существуют разные.

[Pyrus]

Наиболее точное, построчное профилирование, замедляет выполнение кода примерно в 10 раз. Разумеется, мы используем легковесное профилирование, но оно не всегда дают достаточно точную информацию.

[andrey239]

Всё-таки о каких технологиях мы говорим? Надеюсь, Страшного Секрета в этом нет? :)

[return]

Про Pyrus рассказали, а где про обещанные высоконагруженные системы? O.o

[LMik]

Кто-то громко пукнул в лужу… или показалось?

[excoder]

Интересно было бы узнать про опыт с JSON-строками. Сам недавно сталкивался с аналогичной ситуацией. Какие решения пробовали, какая получалась скорость?

[Pyrus]

У нас не было вопроса JSON или какой-либо другой формат данных. Это обусловлено тем, что основным клиентом сервиса является браузер, в котором есть нативная поддержка JSON. Да и во всех мобильных платформах есть много JSON-библиотек.

Вопрос скорее был такой: куда уходит CPU веб сервера и что оптимизировать в первую очередь. Оказалось, что наш собственный код отъедал не более 30%, остальное — gzip и сериализация ответов. Мораль: вначале замеряем, а уже потом ввязываемся в благородное дело кодирования.

Цифры: в самых тяжелых запросах сериализация выполнялась более 400мс (около 8Мб данных до gzip). Нам удалось сократить это до 98мс, но не в общем случае, а конкретно для нашего набора данных. Самая быстрая библиотека общего назначения давала около 200мс.

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

В Google есть много ссылок на сравнения библиотек. Да и на Хабре, кажется, писали обзоры.

[return]

Это же какой json вы отдавали клиенту, если на сериализацию его серверу понадобилось более 400 мс? Что-то здесь не так

[vp_arth]

Написано же — 8МБ, если структура JSON достаточно сложная, то вполне.

[return]

если вы отдаете 8мб json клиенту — значит что-то не так в консерватории, не делайте так вместо переписывания сериализации

[Pyrus]

Верно, это и написано выше — мы решили двигаться в сторону уменьшения объема данных.

[YourSearchExpert]

>>> Так мы выяснили, что 1/3 процессорного времени уходит на… сериализацию: упаковку структур данных в JSON-строки.

JSON действительно не самый быстрый формат сериализации. Я лично пользуюсь msgpack (http://msgpack.org/). По моим тестам на луа он примерно в 2 раза быстрее json. Реализация этого сериализатора есть и на пхп и на других языках программирования. Возможно кому-то будет полезно.

[return]

что значит «быстрый формат»? быстрой или не быстрой может быть только реализация

[Elisy]

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

Вы рассматривали альтернативные форматы? Если да, то какие известные форматы дали большую производительность чем JSON? В итоге в каком виде сериализуются ваши данные?

[Pyrus]

Мы не рассматривали альтернативные форматы, поскольку JSON — стандарт, поддерживается всем браузерами и библиотеки доступны на всех мобильных платформах. В итоге все в JSON и останется в нем в обозримом будущем.