azure - 为什么 Windows Azure 无法扩展？

Question

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

1. 我创建了一个新的共享网站，上面有一个纯 HTML Bootstrap 模板。 http://demobootstrapsite.azurewebsites.net/
2. 然后我从 Apache Project 安装了 ab.exe在托管裸机服务器上(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 个共享实例上运行该网站，但没有任何效果。我的第一个想法是共享实例可能是问题所在。因此，我将该站点放在标准虚拟机上并再次运行测试。但问题依然存在。此外，添加更多实例并没有使网站变得更快(甚至有点慢)。

稍后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)

Answer 1

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

例如；假设小型 VM 每秒可以接受 100 个请求，以 1000 毫秒处理每个请求(如果是每秒 101 个请求，则每个请求将开始减慢至 1500 毫秒)，那么扩展到更多小型 VM 不会提高速度在可以处理单个请求的情况下，它只会使我们每秒接受 200 个请求，每个请求的时间低于 1000 毫秒(因为现在两台机器都没有过载)。

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