HL++ (2009): Twisted Framework 15

Posted by Андрей on Октябрь 13, 2009

Сегодня выступал на HighLoad++ с докладом Twisted Framework – фреймворк для написания сетевых приложений в Python.

Введение

Последнее время в области web происходит смещение внимания с тяжелых application-серверов, которые тратят на обработку запроса сотни миллисекунд, а то и секунды, к более легковесным сервисам, передающим меньшие объемы данных с минимальной задержкой. Переход от генерации десятков и сотен килобайт HTML-кода в ответ на запрос к передаче изменений в данных, запакованных в JSON и измеряемых сотнями байт. В качестве примеров таких сервисов можно привести Gmail, FriendFeed, Twitter Live Search и т.п.

Для обеспечения минимальной задержки для пользователя необходимо либо поддерживать постоянное соединение (например, Adobe Flash, RTMP) или использовать технику HTTP long polling в сочетании с keep alive. Так или иначе на стороне сервера это приводит к появлению большого количества одновременных соединений (тысячи, десятки тысяч), по каждому из которых передается не такой большой объем данных. Эту ситуацию называют обычно проблемой C10k.

Continue reading…

Mongrel vs. Phusion Passenger: выбор очевиден 4

Posted by Андрей on Октябрь 05, 2009

Предыдущая конфигурация:

  • nginx (главный proxy), который раздает трафик в
  • haproxy (ради возможности балансировать по нагрузке), который распределяет нагрузку по нескольким webapp-серверам
  • с 16-ю mongrelами на каждом

Проблемы:

  1. «Утекающая» память, периодический out of memory на серверах, лечится только перезапуском mongrelов.
  2. Запросы, занимающие десятки секунд из-за неверной балансировки (в нагруженный mongrel все-таки попадает несколько «тяжелых» запросов).
  3. Сложность управления кластером монгрелов – постоянные проблемы при перезапуске, «не стартующие» mongrelы и т.п.

Новая конфигурация:

Результат:

webapp01-passenger-mongrel

Комментарий: переход на Phusion Passenger на Week 39, объем занятой памяти – это белая область на графике, растущая сверху вниз. До перехода на Passenger объем свободной памяти стремительно уменьшался, иногда доходя до нуля, после перехода остается более-менее стабильным. Использование CPU осталось на прежнем уровне (как и ожидалось).

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

Так что если вы еще не переключились, мы идем к вам :)

P.S. Отдельное спасибо glebpom за подсказку.