为什么Windows Azure无法扩展?

时间:2013-12-30 20:34:35

标签: azure scalability azure-web-roles

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

  1. 我创建了一个新的共享网站,上面有一个简单的HTML Bootstrap模板。 http://demobootstrapsite.azurewebsites.net/
  2. 然后我从托管裸机服务器上的Apache Project安装了ab.exe(4个内核,12 GB内存,100 MBit)
  3. 我跑了两次测试。第一次使用单个共享实例,第二次使用此命令使用两个共享实例:

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

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

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

    后来I‘ve whatched a Video with Scott Hanselman and 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)
    

6 个答案:

答案 0 :(得分:5)

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

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

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

答案 1 :(得分:3)

鉴于此类测试最重要的细节完全缺席,我觉得您只是在测试您的Internet连接带宽。 10 Mb / sec是一种非常常见的速率。

不,它不会缩放。

答案 2 :(得分:1)

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

答案 3 :(得分:1)

一些想法:

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

答案 4 :(得分:0)

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

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

答案 5 :(得分:0)