Azure 上的 OpenRtb 竞标者，是真的吗？答案

【问题标题】：OpenRtb bidder on Azure, is it real?Azure 上的 OpenRtb 竞标者，是真的吗？
【发布时间】：2014-09-30 05:26:10
【问题描述】：

我们正在尝试在 Azure env 上构建一个 OpenRtb 投标器。我们使用部署在 Linux VM 上的 redis 实例来存储实时数据（跟踪密钥、请求/投标计数等）。我们使用基于 WebApi 的网站（标准计划/大型实例/按性能扩展）作为端点。在 webapi bidder 控制器中，我们使用异步方法，对 DB 和 redis 的所有请求也是异步的。 Json.net 到 ser/der json req/resp.

目前我们遇到了延迟问题。我们应该有可能每秒接收超过 10000 个请求，延迟应该小于 100 毫秒。

有人可以和我分享经验吗？这个技术堆栈是否适合构建像 rtb 投标人这样的应用程序。目前我正在尝试找到存储每个请求的请求上下文（查询、请求正文、标头等）的最佳策略。所以，我需要一种非常快速地插入大量（> 10000）大消息的方法。我在想：

存储到日志文件并将它们复制到 HDFS 并由 Hadoop MapReduce 任务 (HDInsight) 进行解析
使用一些队列，如 AzureQueue 或 ServiceBus 或者 RabbitMQ 并将 req 消息发送到队列，一些服务（自制或 LogStash 等）也会接收它们并存储到一些存储中。

也许有人可以告诉我如何优化延迟和性能，因为目前我们在这方面存在问题。也许是一些基本的陷阱？

【问题讨论】：

您能描述一下您系统的工作流程吗？就像从您收到投标请求到回复时发生的情况一样。以更详细的方式。

标签： c# azure logging statistics

【解决方案1】：

有趣。我对 Azure 的经验很少，但是如果涉及到队列或任何类型的 IO 之类的东西，那么构建具有高吞吐量和低延迟的 rtb 投标者可能会很棘手。仅在必要时使用它们，最好不要使用投标路径。缓存所有内容或在内存存储中使用高速（Aerospike、Couchbase 等 .. 甚至 redis，如果你很聪明的话）。异步很棒，但要小心安排太多线程。如果可以使用 epoll，非阻塞 IO，可能会导致高延迟。我已经构建了一个在 aws 上运行的投标器，netty（jvm 上的异步非阻塞 io）包装在 Twitter 的 Finagle（twitter RPC 系统）上，作为模型缓存的编年史地图和用于数据服务的 aerospike。我们可以在一盒 m4.2xlarge（8 核/32 Go）上处理 20k req/sec，99% 的尾部延迟平均约为 45 毫秒和 16 毫秒。您倾向于阅读您应该只为投标人使用裸机，但更多的是关于架构而不是虚拟化。

【讨论】：

【解决方案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。实际上，在 99 个百分位数小于 11 毫秒的情况下，在单个实例上处理 40k rps 就足够了。实际上，目前 asp.net 5 在速度方面显示出不错的效果，您可以查看here

【讨论】：