我们正在尝试在Azure环境中构建一个OpenRtb出价工具。我们使用部署在Linux VM上的redis实例来存储实时数据（跟踪密钥，请求/ bidwins计数等）。我们使用基于WebApi的网站（标准计划/大型实例/按性能扩展）作为终点。在webapi bidder控制器中，我们使用异步方法，对DB和redis的所有请求也是异步的。 Json.net到ser / der json req / resp。
目前我们遇到延迟问题。我们应该有可能每秒接收超过10000 req，延迟应该<100ms。
有人可以与我分享经验吗？这个技术堆栈是否适合构建像rtb竞标者这样的应用程序。目前，我正在尝试找到存储每个请求的请求上下文（查询，请求正文，标题等）的最佳策略。所以，我需要非常快速地插入大量（＆gt; 10000）大消息的方法。我在考虑：
也许有人可以向我展示如何优化延迟和性能，因为目前我们遇到了这方面的问题。也许是一些基本的陷阱？
答案 0 :(得分：0)
有趣。 我对Azure的经验不多，但如果您涉及队列或任何类型的IO之类的东西，那么构建具有高吞吐量和低延迟的rtb竞标者可能会非常棘手。仅在必要时使用这些，并且最好在出价路径之外。缓存所有内容或在内存存储中使用高速（Aerospike，Couchbase等等。如果你对它很聪明，甚至可以使用redis）。 异步很棒，但是要有太多的线程来安排。这可能会导致高延迟，如果你可以使用epoll，非阻塞IO。 我已经建立了一个在aws上运行的竞标者，在Twitter的Finagle（twitter RPC系统）上包含netty（jvm上的异步非阻塞io），编年史地图作为模型缓存和用于数据服务的aerospike。我们可以在一盒m4.2xlarge（8核/ 32 Go）上处理20k req / sec，99％的尾部延迟大约为45 ms，平均为16 ms。 您倾向于认为您应该只为投标人使用裸机，但它更多的是关于虚拟化与否的架构。
答案 1 :(得分：0)
我们的实施遇到了同样的问题，实际上我们决定检查可能的替代方案。我们对不同的langs和libs进行了基准测试。
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。实际上，它应该在单个实例上处理40k rps，99％的小于11 ms。实际上，目前asp.net 5在速度方面表现出良好的结果，你可以查看here