为啥 Windows Azure 无法扩展？

Posted 2023-02-23

【中文标题】为啥 Windows Azure 无法扩展？

【英文标题】：Why does Windows Azure not scale?为什么 Windows Azure 无法扩展？

【发布时间】：2014-01-17 18:49:22

【问题描述】：

我正在尝试在 Widows Azure 上扩展网站。到目前为止，我已经测试了 Wordpress、Ghost（博客）和一个纯 html 网站，它们都是一样的：如果我扩大它们（添加实例），它们不会变得更快。我确定我一定做错了什么…… 这就是我所做的：

我创建了一个新的共享网站，上面有一个纯 HTML 引导模板。 http://demobootstrapsite.azurewebsites.net/ 然后我在托管的裸机服务器（4 核，12 GB RAM，100 MBit）上从 Apache Project 安装 ab.exe

我进行了两次测试。第一次使用单个共享实例，第二次使用此命令使用两个共享实例：

ab.exe -n 10000 -c 100 http://demobootstrapsite.azurewebsites.net/

这意味着 ab.exe 将使用 100 个并行线程创建 10000 个请求。

我预计使用两个共享实例的测试响应时间会明显低于仅使用一个共享实例的响应时间。但是，每个请求的平均时间甚至从一个共享实例的 1452.519 毫秒上升到两个共享实例的 1460.631 毫秒。后来我什至在 8 个共享实例上运行该站点，但完全没有效果。我的第一个想法是共享实例可能是问题所在。所以我把网站放在一个标准的虚拟机上，然后再次运行测试。但问题仍然存在。此外，添加更多实例并没有使网站更快（甚至更慢）。

稍后I‘ve whatched a Video with Scott Hanselman and Stefan Schackow 他们在其中解释了 Azure 缩放功能。 Stefan 说 Azure 有一种“粘性负载平衡”，它将始终将客户端重定向到同一个实例/VM，以避免与有状态应用程序的兼容性问题。因此，我检查了 WebServer 日志，发现每个实例的日志文件大小大致相同。通常这意味着在测试期间使用了每个实例..

PS：在测试运行期间，我从本地计算机（来自与服务器不同的网络）检查了网站的响应时间，响应时间约为 1.5 秒。

以下是测试结果：

###################################### 
1 instance result
###################################### 

PS C:\abtest> .\ab.exe -n 10000 -c 100 http://demobootstrapsite.azurewebsites.net/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking demobootstrapsite.azurewebsites.net (be patient)
Finished 10000 requests


Server Software:        Microsoft-IIS/8.0
Server Hostname:        demobootstrapsite.azurewebsites.net
Server Port:            80

Document Path:          /
Document Length:        16396 bytes

Concurrency Level:      100
Time taken for tests:   145.252 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      168800000 bytes
HTML transferred:       163960000 bytes
Requests per second:    68.85 [#/sec] (mean)
Time per request:       1452.519 [ms] (mean)
Time per request:       14.525 [ms] (mean, across all concurrent requests)
Transfer rate:          1134.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14   8.1     16      78
Processing:    47 1430  93.9   1435    1622
Waiting:       16  705 399.3    702    1544
Total:         62 1445  94.1   1451    1638

Percentage of the requests served within a certain time (ms)
  50%   1451
  66%   1466
  75%   1482
  80%   1498
  90%   1513
  95%   1529
  98%   1544
  99%   1560
 100%   1638 (longest request)

###################################### 
2 instances result
###################################### 

PS C:\abtest> .\ab.exe -n 10000 -c 100 http://demobootstrapsite.azurewebsites.net/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking demobootstrapsite.azurewebsites.net (be patient)
Finished 10000 requests


Server Software:        Microsoft-IIS/8.0
Server Hostname:        demobootstrapsite.azurewebsites.net
Server Port:            80

Document Path:          /
Document Length:        16396 bytes

Concurrency Level:      100
Time taken for tests:   146.063 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      168800046 bytes
HTML transferred:       163960000 bytes
Requests per second:    68.46 [#/sec] (mean)
Time per request:       1460.631 [ms] (mean)
Time per request:       14.606 [ms] (mean, across all concurrent requests)
Transfer rate:          1128.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14   8.1     16      78
Processing:    31 1439  92.8   1451    1607
Waiting:       16  712 402.5    702    1529
Total:         47 1453  92.9   1466    1622

Percentage of the requests served within a certain time (ms)
  50%   1466
  66%   1482
  75%   1482
  80%   1498
  90%   1513
  95%   1529
  98%   1544
  99%   1560
 100%   1622 (longest request)

【问题讨论】：

这个问题似乎是题外话，因为它是关于应用程序托管而不是开发

微软支持网站说 *** 是获得 Windows Azure 在线帮助的好地方 :) windowsazure.com/en-us/support/forums 但是，是的，也许你是对的。我在这里发布它的原因是，我目前正在开发一个网络应用程序，我想知道为什么它不能扩展。

您是否尝试过并行运行多个 ab 副本？除了单个 ab -n 10000 -c 100 之外，您还可以执行两个 cmd 窗口，或者更好的是两台运行 -n 5000 -c 50 的单独机器。如果这显示出一些差异，则在进一步划分时可能会很有趣。

Offtopic：在分布式高端硬件上运行 Wordpress 就像用优质汽油给轻便摩托车喂食。 D：

@CedricReichenbach 对。这就是为什么我用一个简单的 HTML 站点运行这个测试。使用 Wordpress，SQL 连接将成为瓶颈...

【参考方案1】：

在资源方面“缩放”网站会增加更多容量以接受更多请求，并且不会提高单个容量实例在不过载时的执行速度。

例如；假设小型 VM 每秒可以接受 100 个请求，以 1000 毫秒处理每个请求，（如果每秒 101 个请求，每个请求将开始减慢到 1500 毫秒）然后扩展到更多小型 VM 不会提高速度在可以处理单个请求的情况下，它只会让我们在 1000 毫秒内每秒接受 200 个请求（因为现在两台机器都没有过载）。

对于每个请求的性能；代码本身（以及 Azure VM 的 CPU 性能）将影响单个请求的执行速度。

【讨论】：

这正是我想知道的：1 个 VM 每秒能够处理 68.85 个请求，2 个 VM 每秒可以处理 68.46 个请求。 I 不仅是响应时间，而且 rq/s 也没有提高。

您从一个点（您的计算机）对其进行了测试，对吗？我想这是真正的极限。您可能想研究分布式测试。

@Oliver 请注意，如果您在测试期间使用 keep-alives，您可能仍然连接到单个 VM 实例。在测试期间关闭 HTTP keep-alives，或使用更好的负载测试服务，如免费（而且非常棒）loader.io 站点如果您通过 Azure 的管理门户附加组件添加它，您也可以免费获得一些额外的东西。

@CedricReichenbach 我还通过 Team Foundation 基于云的负载测试对其进行了测试，以验证它。 blogs.msdn.com/b/visualstudioalm/archive/2013/06/03/…

我同意@Andrew 的观点，看来您期望更快的响应时间。你不是在扩大规模，而是在扩大规模。真正的测试是在一个实例上增加请求，直到您看到不可接受的响应时间，然后引入第二个实例以查看情况是否有所改善。你没有抛出足够多的请求，对于绝对最慢的请求来说，1.6 秒算不上什么。

【参考方案2】：

鉴于此类测试最重要的细节问题完全没有，在我看来，您只是在测试您的 Internet 连接带宽。 10 Mb/sec 是一个非常常见的速率。

不，它不能扩展。

【讨论】：

请帮帮我。负载测试最重要的细节是什么？为避免带宽问题，我在具有 100 Mbit 互联网连接的托管服务器上对其进行了测试。我不确定服务器连接是否足够。因此，我使用 Windows Azure 负载测试进行了进一步的测试，这些测试显示了相同的结果。

识别瓶颈是最重要的细节。您有很好的（未经测试的）证据表明 Azure 不存在此问题，因此请务必考虑其他解释。网络带宽当然是一个不错的选择，了解更多关于硬件和基础设施的信息。与您的 LAN 管理员和 ISP 交谈，他们应该知道这些详细信息。

我目前无法解释这个问题。这就是为什么我把它贴在这里。我也不敢相信这真的是 Windows Azure 的问题。因此，我使用 Team Foundation Service (blogs.msdn.com/b/visualstudioalm/archive/2013/06/03/…) 使用基于云的负载测试进行了另一项测试。这些测试直接在 Windows Azure 上运行，所以我的 ISP 基础设施应该没有问题。但是这个测试显示的结果与我上面发布的测试相同。这与抨击 Azure 无关，我只是想让它为我工作。

如果您遇到带宽限制，您可能想尝试loader.io 我已经取得了很大的成功。

【参考方案3】：

我通常针对负载测试时生成的 iis 日志运行 logparser，然后计算 RPS 和延迟（耗时字段）。这有助于将缓慢从网络、服务器处理到实际负载测试工具报告隔离开来。

【讨论】：

我没有使用 logparser，但我查看了日志以了解是否真的两个 VM 都被击中了。 IIS 日志中的响应时间在我看来是合理的（+- 5% 比 ab test 所说的）

在横向扩展时响应时间将保持不变，因为每个 VM 上的请求执行时间都相同。横向扩展将处理更多请求/秒，每个请求的响应时间相同。为了提高响应时间，扩大规模将有所帮助。您可以将每个请求的响应时间与同一应用程序的分片模式 VM 和标准模式 VM 进行比较。

需要记住的一点是共享虚拟机具有配额强制。负载过高后，您的网站将被限制并开始被重定向到默认页面，这将是 302 响应，并且会扭曲响应时间数字。因此，您应该真正解析出每个特定页面的比较。静态文件内容将缓存在从客户端到服务器的不同位置，并对响应时间产生巨大影响。由于第一次请求的冷启动激活，在测试中间限制并重新启动站点会扭曲响应时间。

尝试使用特定页面（可能是动态联系）和标准虚拟机运行类似的测试。这将有助于进一步隔离。

【参考方案4】：

一些想法：

Azure 是否通过节流来防止 DOS 攻击？您正在从一个位置向一个页面发出大量请求。 尝试使用小型网站而不是共享网站。容量和扩展可能完全不同。对于共享服务来说，每秒 50 个请求的负载似乎并不可怕。 尝试确定时间的去向。 1.4s真的很长。 同时从多台不同的机器上运行负载测试，以确定是否存在限制，或者您是否受到粘性负载平衡或其他网络伪影的影响。 您说在 50 个请求/秒的大约 10 个并发请求的负载下是可以的。逐渐增加您在服务器上的负载，以确定它开始阻塞的点。也可以在多台机器上执行此操作。 您可以登录网站吗？可能不会......看看您是否可以在云服务 Web 角色上复制相同的问题，并使用性能监视器和典型的 IIS 工具从那里进行分析，以查看瓶颈在哪里，或者它是否在机器上与 Azure 网络基础设施。

【参考方案5】：

在对网站进行负载测试之前，您应该使用单个实例（例如使用 10 个并发线程）进行基线测试，以检查网站在未加载时的处理方式。然后使用此基线来了解网站在负载下的行为。

例如，如果基线显示网站在没有负载时会在 1.5 秒内响应请求，而在负载下又会在 1.5 秒内响应，那么这意味着网站能够轻松处理负载。如果网站在负载下使用单个实例需要 3-4 秒，那么这意味着它不能很好地处理负载 - 尝试添加另一个实例并检查响应时间是否有所改善。

【讨论】：

我做了一个有 10 个并发线程的基线测试：平均响应时间是 200 毫秒，每秒 50 个请求。当我在单个 VM 上使用更多并发线程运行测试时，Web 服务器开始对请求进行排队，并且响应时间变慢。 （例如，100 个线程的平均响应时间高达 1452 毫秒）。但是当我添加第二个虚拟机时，情况并没有好转。甚至每秒的请求数也没有好转。当单个 VM 可以处理 50 / 60 rq/s 时，2 个 VM 应该可以处理大约 100 rq/s，但如测试结果所示，2 个 VM 也只能处理 60 rq/s。

@Oliver：将这些基线数字添加到问题中。当您增加此负载时，查看响应时间也很好。也许有一点，2 个 VM 的性能比 1 个好得多，但是当您达到 100 个线程时，对于 2 个 VM 来说就太多了，您会看到与 1 个具有 50 个线程的 VM 相同的响应时间。

【参考方案6】：

这里 您可以免费测试 http://tools.pingdom.com/fpt/#!/ELmHA/http://demobootstrapsite.azurewebsites.net/

http://tools.pingdom.com/

问候 瓦伦丁