Comments 25
мне кажется, или эта статья — пиар-акция вашей компании?
Вы так говорите, как будто это что-то плохое.
А если серьезно — нам нравится делать полезные вещи. Кому-то наша система приносит пользу, а кто-то, мы надеемся, извлечет пользу из этого текста.
А если серьезно — нам нравится делать полезные вещи. Кому-то наша система приносит пользу, а кто-то, мы надеемся, извлечет пользу из этого текста.
я ничего против не имею ни против вас, ни против того что вы делаете. Просто прочитав, я понял, что вы — клевые(наверное, так и есть), но ничего нового не узнал — вот, что я имел ввиду, что разделу статья не очень соответствует. ее б лучше в «я пиарюсь»
6. Желтый снег есть нельзя. Обязательно добавьте, это важный урок.
А если серьезно — голые факты и метафоры вылетают из головы сразу после прочтения, какими бы ценными они не были. Стоит поэкспериментировать с подачей материала, возможно истории из жизни и личный опыт отложился бы в умах читателей куда прочнее очередного набора «100 вещей, которые вы должны сделать завтра».
Кто-нибудь читая этот комментарий вспомнит какой был урок №2 не отматывая вверх? То-то же.
А если серьезно — голые факты и метафоры вылетают из головы сразу после прочтения, какими бы ценными они не были. Стоит поэкспериментировать с подачей материала, возможно истории из жизни и личный опыт отложился бы в умах читателей куда прочнее очередного набора «100 вещей, которые вы должны сделать завтра».
Кто-нибудь читая этот комментарий вспомнит какой был урок №2 не отматывая вверх? То-то же.
Спасибо за комментарий. Как вы, наверное, заметили, это пост с пометкой «из песочницы». Т.е. он у нас тут первый. Будем пробовать писать истории в другом формате.
Какой был урок №2 и правда не могу, зато могу перечислить все пять не по порядку…
Хотя безусловно вы правы, суховато…
Хотя безусловно вы правы, суховато…
мы приняли непопулярное решение: написать свою
Для высоконагруженного приложения — это самое популярное решение.
Там, где идет борьба за миллисекунды нет места библиотекам общего назначения…
> Запускать профайлер на боевом сервере практически невозможно – он добавляет слишком много накладных расходов и сервис начинает тормозить
A/B подход?
A/B подход?
> Запускать профайлер на боевом сервере практически невозможно – он добавляет слишком много накладных расходов и сервис начинает тормозить
Что-то тут не так. Мы примерно о каких технологиях говорим? apache? tomcat? php?
Профайлеры бывают разные и способы профилирования существуют разные.
Что-то тут не так. Мы примерно о каких технологиях говорим? apache? tomcat? php?
Профайлеры бывают разные и способы профилирования существуют разные.
Про Pyrus рассказали, а где про обещанные высоконагруженные системы? O.o
Кто-то громко пукнул в лужу… или показалось?
Интересно было бы узнать про опыт с JSON-строками. Сам недавно сталкивался с аналогичной ситуацией. Какие решения пробовали, какая получалась скорость?
У нас не было вопроса JSON или какой-либо другой формат данных. Это обусловлено тем, что основным клиентом сервиса является браузер, в котором есть нативная поддержка JSON. Да и во всех мобильных платформах есть много JSON-библиотек.
Вопрос скорее был такой: куда уходит CPU веб сервера и что оптимизировать в первую очередь. Оказалось, что наш собственный код отъедал не более 30%, остальное — gzip и сериализация ответов. Мораль: вначале замеряем, а уже потом ввязываемся в благородное дело кодирования.
Цифры: в самых тяжелых запросах сериализация выполнялась более 400мс (около 8Мб данных до gzip). Нам удалось сократить это до 98мс, но не в общем случае, а конкретно для нашего набора данных. Самая быстрая библиотека общего назначения давала около 200мс.
Есть шансы ускорить сериализацию еще, но мы решили двигаться в сторону уменьшения объема данных.
В Google есть много ссылок на сравнения библиотек. Да и на Хабре, кажется, писали обзоры.
Вопрос скорее был такой: куда уходит CPU веб сервера и что оптимизировать в первую очередь. Оказалось, что наш собственный код отъедал не более 30%, остальное — gzip и сериализация ответов. Мораль: вначале замеряем, а уже потом ввязываемся в благородное дело кодирования.
Цифры: в самых тяжелых запросах сериализация выполнялась более 400мс (около 8Мб данных до gzip). Нам удалось сократить это до 98мс, но не в общем случае, а конкретно для нашего набора данных. Самая быстрая библиотека общего назначения давала около 200мс.
Есть шансы ускорить сериализацию еще, но мы решили двигаться в сторону уменьшения объема данных.
В Google есть много ссылок на сравнения библиотек. Да и на Хабре, кажется, писали обзоры.
>>> Так мы выяснили, что 1/3 процессорного времени уходит на… сериализацию: упаковку структур данных в JSON-строки.
JSON действительно не самый быстрый формат сериализации. Я лично пользуюсь msgpack (http://msgpack.org/). По моим тестам на луа он примерно в 2 раза быстрее json. Реализация этого сериализатора есть и на пхп и на других языках программирования. Возможно кому-то будет полезно.
JSON действительно не самый быстрый формат сериализации. Я лично пользуюсь msgpack (http://msgpack.org/). По моим тестам на луа он примерно в 2 раза быстрее json. Реализация этого сериализатора есть и на пхп и на других языках программирования. Возможно кому-то будет полезно.
Реализация для конкретно наших задач работала в 2 раза быстрее самого быстрого доступного на рынке альтернативного решения.
Вы рассматривали альтернативные форматы? Если да, то какие известные форматы дали большую производительность чем JSON? В итоге в каком виде сериализуются ваши данные?
Sign up to leave a comment.
5 уроков для разработчиков высоконагруженных систем