我们在Azure负载均衡器后面有2个Elastic VM（Linux）（当前为DS2V2）。我们正在从本地局域网向负载均衡器发送HTTP消息，但似乎受到限制。我们尝试过：更改VM的大小，没有区别；添加额外的高级固态硬盘，同样没有区别；在我们的一端运行多个线程，再次没有区别。
但是，我们要做的是让Elastic Engine从Linux机器中吸取所有日志文件，并且在摄取它们时，索引率跳得很高。因此，我们假设不是限制我们的Linux弹性盒。
我们确实在盒子上安装了Kibana，作为基线，我们只是对盒子上的本地帖子和日志文件的本地摄取都使用了“集群索引率”。
我们的确知道，是的，由于我们现在正在涉及互联网，所以会有一些延迟和开销，但是目前所获得的费率却没有。 （我们有一个通往互联网的1G管道，容量远不及它，因此我们至少可以排除脱离我们公司的麻烦。）
问题是，我们还能在哪里确定可能受到限制的地方？
对于性能“慢得多”，这是一个主观的问题，很难识别。我只是提供一些可能会影响它的信息。
Azure计算请求可能会在订阅时和每个区域的基础上受到限制。如果您遇到API节流错误，则可以参考this document对节流问题进行故障排除，以及避免被节流的最佳实践。
某些因素上Azure VM大小的CPU和存储限制可能会影响Azure VM处理传入数据。您可以将大小更改为更高的CPU和高级SSD磁盘。您还可以将Azure资源更改到您所在位置附近的另一个区域。您可以参考this article。