Pull to refresh
2
0
Send message
Не бойтесь удалять нерабочий код, система контроля версий о нём не забудет!
Народная программистская мудрость. ;-)
Совершенно верно, жёсткого лимита нет.

Да, действительно нагрузки здесь очень маленькие. Параллельность обработки запросов обеспечивается за счёт асинхронной работы приложения. Само приложение работает на IIS и особых чудес в производительности от него ждать не приходиться, но с текущей нагрузкой он справляется. Нагрузка растёт не мгновенно, а в случае нехватки мощностей конечно будем разбираться, например можно посмотреть в сторону проекта Katana, тем более что у нас уже есть опыт работы с ним.
В сыром виде статистика пишется в Aerospike. Далее, каждые 5 минут, она агрегируется и перекочёвывает в PostgreSQL. С ним уже работает клиентская часть.
Благодарим за внимательность, схему мы поправили.

По поводу производительности. В среднем входящий трафик составляет 150 — 200 запросов в секунду, бывают пики до 1000 запросов в секунду, всё это обрабатывают два сервера с 6 экземплярами приложения в пуле каждый. Таким образом нагрузка на один экземпляр приложения 12 — 16 запросов в секунду. На DSP уходит весь этот трафик. Максимальное время обработки запроса складывается из времени ответа DSP (максимум мы ждём 120 миллисекунд) плюс 10 — 20 миллисекунд время работы самой SSP, в итоге максимум 140 миллисекунд.

Information

Rating
Does not participate
Registered
Activity