问题 为什么Windows Azure无法扩展?


我正在尝试在Widows Azure上扩展网站。到目前为止,我已经测试了Wordpress,Ghost(博客)和纯HTML网站,它们都是一样的:如果我扩展它们(添加实例),它们就不会更快。我相信我一定做错了... 这就是我做的:

  1. 我创建了一个新的共享网站,上面有一个简单的HTML Bootstrap模板。 http://demobootstrapsite.azurewebsites.net/
  2. 然后我从中安装了ab.exe Apache项目 在托管的裸机服务器上(4核,12 GB RAM,100 MBit)

我跑了两次测试。第一次使用单个共享实例,第二次使用此命令使用两个共享实例:

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

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

我希望两个共享实例的测试响应时间明显低于只有一个共享实例的响应时间。但是每个请求的平均时间甚至从一个共享实例的1452.519毫秒增加到两个共享实例的1460.631毫秒。后来我甚至在8个共享实例上运行了该站点,完全没有任何效果。我的第一个想法是,共享实例可能是问题所在。所以我将网站放在标准VM上并再次运行测试。但问题仍然存在。此外,添加更多实例并不会使网站更快(甚至更慢)。

后来 我跟Scott Hanselman和Stefan Schackow一起拍了一段视频 他们在其中解释了Azure Scaling功能。 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)

5664
2017-12-30 20:34


起源

这个问题似乎是偏离主题的,因为它是关于应用程序托管而不是开发 - Mark
微软支持网站称,Stackoverflow是获取Windows Azure在线帮助的好地方:) windowsazure.com/en-us/support/forums 但是,是的,也许你是对的。我在这里发布它的原因是,我正在开发一个网络应用程序,我想知道为什么它不能扩展。 - Oliver
您是否尝试过并行运行多个ab副本?而不是单个ab -n 10000 -c 100你可以做两个cmd窗口或更好的两个单独的机器运行-n 5000 -c 50.如果这显示出一些差异,在进一步划分它可能会很有趣。 - Kyle Hodgson
Offtopic:在分布式高端硬件上运行Wordpress就像用优质汽油喂养轻便摩托车一样。 d: - Cedric Reichenbach
@CedricReichenbach对。这就是为什么我用一个简单的HTML网站运行这个测试。使用Wordpress,SQL连接将成为瓶颈...... - Oliver


答案:


在资源方面“扩展”网站增加了更多容量来接受更多请求,并且不会增加单个容量实例在未过载时可以执行的速度。

例如;假设一个小型虚拟机可以接受每秒100个请求,在1000毫秒处理每个请求,(如果每秒有101个请求,每个请求将开始减慢到1500毫秒),那么扩展到更小的虚拟机将不会提高速度可以处理单个请求,它只是让我们在每个1000毫秒内接受每秒200个请求(因为现在两台机器都没有超载)。

对于按请求的性能;代码本身(以及Azure VM的CPU性能)将影响单个请求的执行速度。


5
2017-12-31 19:26



这正是我想知道的:1个VM能够处理每秒68.85个请求,2个VM可以处理每秒68.46个请求。我不仅是响应时间,也是rq / s的改进。 - Oliver
您是从一个单点(您的计算机)测试过的,对吗?我想这是真正的限制。您可能希望研究分布式测试。 - Cedric Reichenbach
@Oliver请注意,如果您在测试期间使用了keep-alives,则可能仍然连接到单个VM实例。在测试期间关闭HTTP保持活动,或使用更好的负载测试服务,如免费(和漂亮的rad) loader.io 站点如果您通过Azure的管理门户附加组件添加它,您也可以免费获得一些额外的东西。 - Andrew
@CedricReichenbach我也通过Team Foundation基于云的负载测试对其进行了测试,以验证它。 blogs.msdn.com/b/visualstudioalm/archive/2013/06/03/... - Oliver
我同意@Andrew,看起来你期待更快的响应时间。你没有扩大规模,你正在扩展。真正的测试是在一个实例上增加请求,直到看到不可接受的响应时间,然后引入第二个实例以查看情况是否有所改善。你没有投掷足够的请求,1.6秒对于绝对最慢的请求几乎没有冰。 - ShaunUK


鉴于此类测试最重要的细节问题完全没有,我觉得你只是测试你的互联网连接带宽。 10 Mb / sec是一种非常常见的速率。

不,它不会扩展。


3
2018-01-02 01:07



请帮帮我。负载测试最重要的细节是什么?为避免带宽问题,我在具有100 Mbit网络连接的托管服务器上进行了测试。我不确定服务器连接是否足够。所以我使用Windows Azure负载测试进行了进一步的测试,这些测试显示了相同的结果。 - Oliver
确定瓶颈是最重要的细节。你有很好的(未经测试的)证据表明Azure没有这个问题,所以一定要考虑其他解释。网络带宽当然是一个很好的选择,了解有关硬件和基础设施的更多信息。与您的局域网管理员和您的ISP交谈,他们应该知道这些细节。 - Hans Passant
我目前没有解释这个问题。这就是为什么我在这里发布它。我也无法相信这是Windows Azure真正的问题。所以我使用Team Foundation Service进行了基于云的负载测试的另一项测试(blogs.msdn.com/b/visualstudioalm/archive/2013/06/03/...)。这些测试直接在Windows Azure上运行,因此我的ISP基础设施应该不是问题。但是这个测试显示了与我上面发布的测试相同的结果。这不是关于Azure抨击,我只是想让这个为我工作。 - Oliver
如果您遇到带宽限制,可能需要尝试 loader.io  我和他们取得了很大的成功。 - Homer6


我通常对负载测试时生成的iis日志运行logparser,并计算RPS和延迟(取消时间字段)。这有助于隔离从网络,服务器处理到实际负载测试工具报告的缓慢。


1
2018-01-07 02:18



我没有使用logparser,但是我看了一下日志,看看是不是两个VM都被击中了。 IIS日志中的响应时间对我来说看起来很合理(对于ab测试说的是+ - 5%) - Oliver
扩展时响应时间将保持不变,因为请求执行将在每个VM上花费相同的时间。横向扩展将处理更多请求/秒,每个请求具有相同的响应时间。为了提高响应时间,扩展将有所帮助。您可以将每个请求的响应时间与同一应用程序的分片模式VM和标准模式VM进行比较。 - Apurva
要记住的几件事情是共享虚拟机具有配额强制执行。在负载过高后,您的站点将受到限制,并将开始重定向到默认页面,这将是302响应,它将使响应时间数字偏斜。所以你应该真正解析每个特定页面的比较。静态文件内容将缓存在客户端到服务器的不同位置,并对响应时间产生巨大影响。由于第一次请求的冷启动激活,在测试过程中限制并重新启动站点会使响应时间产生偏差。 - Apurva
尝试使用特定页面(可能是动态联系人)和标准VM运行类似的测试。这有助于进一步隔离。 - Apurva


一些想法:

  • Azure是否会限制以防止DOS攻击?您正在从一个位置到一个页面进行大量请求。
  • 尝试小型网站而不是共享。容量和扩展可能会有很大不同。对于共享服务,50请求/秒的负载似乎并不可怕。
  • 尝试确定那个时间的去向。 1.4s是一个很长的时间。
  • 同时从多个不同的计算机运行负载测试,以确定是否正在进行限制,或者您受到粘性负载平衡或其他网络伪影的影响。
  • 你说在50次请求/秒下加载大约10个并发请求是可以的。逐渐增加您在服务器上的负载,以确定它开始窒息的点。在多台机器上也这样做。
  • 你可以登录网站吗?可能不是......看看您是否可以在云服务Web角色上复制相同的问题,并使用性能监视器和典型的IIS工具从那里进行分析,以查看瓶颈在哪里,或者甚至在机器上与Azure网络基础架构相比。

1
2018-01-08 21:27





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

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


0
2018-01-01 13:45



我使用10个并发线程进行了基线测试:平均响应时间为200毫秒,每秒50个请求。当我在单个VM上使用更多并发线程运行测试时,Web服务器开始对requets进行排队,响应时间变慢。 (例如,最多1452ms表示100个线程的响应时间)。但是当我添加第二个VM时,不要变得更好。即使是每秒的反应也没有变得更好。当一个VM可以处理50/60 rq / s时,2个VM应该处理大约100 rq / s,但是测试结果显示,2个VM也只能处理60 rq / s。 - Oliver
@Oliver:将这些基线数添加到问题中。当你增加这个负载时,看到响应时间也是很好的。也许有两个虚拟机比1更好的点,但是当你达到100个线程时,它对于2个虚拟机来说太多了,你看到的响应时间与1个拥有50个线程的虚拟机相同。 - Rory


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

http://tools.pingdom.com/

问候 瓦伦丁


0
2018-01-08 15:57