Как наименее накладно обрабатывать 5-6М очень мелких запросов в сутки?

Question

[xSkyFoXx]

Я располагаю веб-сервисом, который реализует API. К данному API (REST) на вход прилетают очень-очень короткиe сообщения вида:
{
client_key: «my_secret_key»,
ip: «10.128.225.66»,
user: «testuser»,
…
}
И так далее. В совокупности в сообщении 10+-2 очень коротких поля. У меня стоит очень быстрое шардированное (MongoDB) хранилище (оно изрядно подросло за время длительного использования). Но я уперся в производительность сервера (Apache) отвечать на такое количество очень мелкоатомарных запросов. Запросы распределены не равномерно, а сосредоточены в основном в группе пиков. Как бы выкрутиться, не обновляя железо и не устанавливая loadbalancer? Может попробовать что-то другое вместо апача или взять для него какой-то мод? Apache просто «из коробки» в Ubuntu Server 12.04.1 LTS.

Comments

[Moxa]

сколько реквестов в секунду на пике получается? и чем пишете в монгу? php?

[xSkyFoXx]

В пиках 100-200 запросов в секунду. Выдерживал с трудом. Совпало, что было 700 — упал на некоторое время с потерей, соотв, клиентов.

Answer 1

[Moxa]

можно поставить tomcat, реализовать апи на яве… простенький сервлет у меня на ноуте обрабатывает ~12к реквестов в секунду… в таком случае все скорее упрется в скорость записи монги…

Answer 2

[Stdit]

Возможно, nodejs для этого подойдёт.

Comments

[Stdit]

А одинаковые ответы можно попробовать кешировать nginx-ом.

Answer 3

[Алексей Акулович]

Может покрутить настройки воркеров апача? Под вашей нагрузкой он может неоправданно часто перезапускать «рабочих». А у вас, как я понял, он настроен «из коробки».
Ну в догонку, стоит ли у вас APC или эквивалентный кешер?

Comments

[Алексей Акулович]

Еще, как вариант, посмотреть в сторону phpDaemon:
>>asynchronous server-side framework of network applications implemented in PHP using famous libevent…
>>Network clients:
>>MongoDB client

Но я не пробовал его на продакшене. Может кто расскажет о своем опыте.

Answer 4

[iXCray]

YAWS/nginx + php-fastCGI, в этом случае Вы дополнительно выигрываете в возможности держать постоянное соединение с МонгоДБ.

Есть есть такие запросы, ответы на которые можно кешировать, то цепляете ramfs, внутрь папку для кеширования, на эту папку завязываете nginx, чтобы кешировал ответы на определенные запросы.

Answer 5

[Виталий Перетятько]

nginx вместо апача поставьте
данные из этих ваших запросов надо просто сохранять в MongoDB или еще какая то обработка требуется?

Answer 6

[Алексей Ашурок]

Выкинуть Apache, поставить nginx. Если запросы идут через php — php-fpm и в путь.
Есть однотипные запросы? nginx и fastcgi_cache (хотя не уверен что оно надо)
Не нужна лишняя прослойка? Самый отчаяный вариант:
openResty (nginx приправленый lua и какой-то матерью) + mongol
И имеем схему — nginx -> mongo без какого-либо оверхеда. Всё круто, здорово, асинхронно.

Не выдерживает mongo? Поднимаем еще инстанс, прописываем его в апстрим nginx — радуемся!

Навертеть можно что угодно и как угодно, важно понимать как оно будет работать и где bottleneck

Comments

[Алексей Ашурок]

И да, тюнить всё. монгу (не знаю, не сталкивался), nginx — воркеры, треды, ulimit, поставить мониторинг (хотя бы munin, под обработку данных — другая машина, на сервере только munin-клиент)

[Алексей Ашурок]

А самый щадащий вариант — поставить перед apache — nginx. Полегчать — не полегчает, но на медленных клиентах хоть какой-то профит будет.

Answer 7

[justthefish]

Плюсую nginx + кеш на ramfs

Если и этого не хватит — можно употребить жуткую экзотику, типа
github.com/vii/teepeedee2

Comments

[Антон Кузнецов]

А в чем смысл этого извращения — принудительно заставлять писать файлы в память? ОС-то не дурнее будет, сама закэширует в память что посчитает нужным.

[justthefish]

Это извращение — очень-очень быстрый вебсервер для отдачи мелких динамических страниц.
Возможно, самый быстрый. Но стопроцентно утверждать не стану, сравнения не проводил :)

Answer 8

[Александр Борисович]

www.opennet.ru/opennews/art.shtml?num=36779