Участник OpenRtb на Azure, это правда?

Question

Мы пытаемся создать заявку OpenRtb на Azure env. Мы используем экземпляры redis, которые были развернуты на виртуальной машине Linux для хранения данных в реальном времени (ключи отслеживания, количество запросов/битвингов и т. Д.). В качестве конечной точки мы используем веб-сайт на основе WebApi (стандартный план/большие экземпляры/масштабирование по производительности). В контроллере участника webapi мы используем async-методы, все запросы к DB и redis также async. Json.net to ser/der json req/resp.

В настоящее время у нас есть проблемы с задержкой. У нас должна быть возможность получать более 10000 реакторов в секунду, а латентность должна быть < 100 мс.

Может ли кто-нибудь поделиться опытом со мной? Является ли этот технический стек хорошим для создания приложений, таких как участники rtb. В настоящее время я пытаюсь найти лучшую стратегию для хранения контекста запроса (запрос, тело запроса, заголовки и т. Д.) Для каждого запроса. Итак, мне нужно очень быстро вставить много (> 10000) больших сообщений. Я думаю о том:

1. хранения в лог-файлы и скопировать их в HDFS и разбор задач по Hadoop MapReduce (HDInsight)
2. используя некоторую очередь таких, как AzureQueue или ServiceBus или, может быть RabbitMQ и отправить REQ сообщения в очередь , а некоторые службы (самодельные или такие, как LogStash) будут получать их и хранить в некоторых хранилищах.

Возможно, кто-то может показать мне, как оптимизировать латентность и производительность, потому что в настоящее время у нас есть проблемы с этим. Может быть, некоторые основные подводные камни?

Answer 1

Интересно. У меня мало опыта работы с Azure, но создание участников rtb с высокой пропускной способностью и низкой задержкой может быть сложным, если вы включаете такие вещи, как очереди или любые типы ввода-вывода. Используйте их только в случае необходимости и, предпочтительно, из пути подачи заявок. Кэшируйте все или используйте высокую скорость в хранилище памяти (Aerospike, Couchbase и т. Д. Даже redis, если вы умны в этом). Async отлично, но осторожно, имея слишком много потоков для расписания. которые могут вызвать высокую задержку, если вы можете использовать epoll, не блокируя IO. Я построил ставку на aws, с netty (async non blocking io на jvm), завернутый в Finagle Twitter (twitter RPC system), хроническую карту в качестве кэширования модели и аэросику для обработки данных. Мы могли обрабатывать 20k req/sec на одном ящике m4.2xlarge (8 ядер/32 Go) с латентностью хвоста 99 процентилей около 45 мс и 16 мс в среднем. Вы, как правило, читаете, что вы должны использовать только голый металл для участников торгов, но это больше касается архитектуры, виртуализации или нет.

Answer 2

У нас была такая же проблема с нашей реализацией, и на самом деле мы решили проверить возможные альтернативы. Мы сравнивали разные языки и библиотеки.

source Yandex.Tank response per second(ubuntu vm 8 cores) 
target ubuntu vm 8 cores 
golang fast http 30k+ 
nginx 20k 
golang http 20k- 
haskell wai warp 15k+ 
clojure http-kit 15k- 
node.js 7k 
rust hyper 10k+ 
rust iron 10k- 
fsharp suave.io 4k+ (best result ever for .net web servers) 
asp.net 5 kestrel coreclr/mono ??? 400- 

Итак, после этого мы начали использовать golang + fasthttp + redis. На самом деле достаточно было обработать 40 кбит/с в одном экземпляре с 99 процентилями меньше 11 мс. На самом деле в настоящее время asp.net 5 показывает хорошие результаты в скорости, которую вы могли бы проверить here