9 июня(суббота) 2012 Москва

Телефон: +7 (495) 502-33-78
E-mail: 2012@devconf.ru

Архив 2012 года - актуальная информация тут

Кругом обман или использование стандартных протоколов для нестандартных вещей

Александр Клестов. Программист компании Wapstart.
Доклад(30 мин)    Презентация (pdf, 401 Kb)

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

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

Подробно:
Выкинуть весь накопленный код и начать с нуля - это плохой вариант по нескольким причинам:
1. возможность ошибиться при переносе логики;
2. существенное время разработки и тестирования;
3. проект большой, есть ненулевая вероятность что-нибудь "потерять";
4. это очевидно. :)

В нашем проекте часть бизнес-логики документирована плохо или недокументирована совсем. Кусочки требований разных лет плотно осели в коде. Мы решили постепенно повышать производительность не переписывая код большими кусками.

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

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

Логику подбора баннера можно условно разделить на три части:
1. определение характеристик запроса;
2. подбор баннеров, подходящих под запрос из предподготовленных списков;
3. разнообразные отсечки на времени выполнения.

Для нас узким местом оказалась реализация п. 1 - она иногда ходила в базу. От этого мы получали два типа проблем:
1. длинный хвост - кеш работает очень быстро, но 2% уходит в базу и работает медленно;
2. специфичный запрос мог целиком уйти в базу и доставить проблем.

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

О самой реализации, я расскажу в докладе. Тут лишь поделюсь некоторыми результатами:
1. держит 1000 rps на одном ядре на production-серверах (при тестировании держал гораздо больше);
2. по скорости работы сопоставим с Redis.

Собственная реализация "кэша" позволила нам всегда отвечать из памяти, при этом терять менее 1% запросов по распознаванию при ttl кеша в сутки.


Программа конференции