Pull to refresh

Comments 6

На второй картинке, похоже, ошибка — вместо второго «опрос DSP» должен быть «ответ DSP».

Не ясно, зачем на графике две отправки данных в DMP и ни одного получения. Если мы рассматриваем «свою» DSP, то там должно быть получение. Если же «чужую» — то там снова и отправка, и получение данных (если SSP не скрывает информацию о посещении).

И хочется цифр: сколько запросов в секунду обрабатывает один SSP-сервер, сколько запросов в секунду с него уходит на DSP, и сколько максимум времени обрабатывается запрос от браузера.
Благодарим за внимательность, схему мы поправили.

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

«нагрузка на один экземпляр приложения 12 — 16 запросов в секунду» — возможно, я чего-то не понимаю в .NET, но это какие-то очень маленькие цифры. Один эксземпляр обрабатывает один запрос одновременно? Что будет с сервером, когда придёт нормальная нагрузка в 50к запросов в секунду?

SSP на netty (Pure Java NIO), обрабатывает по 10к запросов / секунду на инстанс, по инстансу на сервер, загружая пару CPU.
Совершенно верно, жёсткого лимита нет.

Да, действительно нагрузки здесь очень маленькие. Параллельность обработки запросов обеспечивается за счёт асинхронной работы приложения. Само приложение работает на IIS и особых чудес в производительности от него ждать не приходиться, но с текущей нагрузкой он справляется. Нагрузка растёт не мгновенно, а в случае нехватки мощностей конечно будем разбираться, например можно посмотреть в сторону проекта Katana, тем более что у нас уже есть опыт работы с ним.
Понятно, что существенная часть кода опущена ( «dspUrls.DspRecords» на это намекает ). Но ещё интересно, куда и как вы статистику пишете.
В сыром виде статистика пишется в Aerospike. Далее, каждые 5 минут, она агрегируется и перекочёвывает в PostgreSQL. С ним уже работает клиентская часть.
Sign up to leave a comment.