效率,基准测试,速度测试,性能

时间:2009-01-28 12:02:04

标签: php performance profiling benchmarking

我正在尝试编写一个我试图衡量其效率的脚本。我有几个问题: -

  1. 对于小型应用程序,是否需要这种分析?还是我变得偏执? (假设大多数代码效率很高/没有无限循环)
  2. 反对我应该对此进行基准测试?我该怎么比较?
  3. 以下是我从ab获得的效率输出。这样太过分了吗?我是否正朝着设计此应用程序的错误方向前进?我应该注意哪些警告信号?
  4. abs -n10000 -c100 http://localhost/testapp
    
    This is ApacheBench, Version 2.3 
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    Benchmarking localhost (be patient)
    Completed 1000 requests
    Completed 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Completed 10000 requests
    Finished 10000 requests
    
    
    Server Software:        Apache/2.2.10
    Server Hostname:        localhost
    Server Port:            80
    
    Document Path:          /testapp
    Document Length:        525 bytes
    
    Concurrency Level:      100
    Time taken for tests:   33.608 seconds
    Complete requests:      10000
    Failed requests:        5179
       (Connect: 0, Receive: 0, Length: 5179, Exceptions: 0)
    Write errors:           0
    Total transferred:      6973890 bytes
    HTML transferred:       5253890 bytes
    Requests per second:    297.55 [#/sec] (mean)
    Time per request:       336.080 [ms] (mean)
    Time per request:       3.361 [ms] (mean, across all concurrent requests)
    Transfer rate:          202.64 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    1   1.5      0     109
    Processing:     8  334 403.9    176    3556
    Waiting:        7  334 403.9    176    3556
    Total:          9  335 403.8    177    3556
    
    Percentage of the requests served within a certain time (ms)
      50%    177
      66%    296
      75%    415
      80%    519
      90%    842
      95%   1141
      98%   1615
      99%   1966
     100%   3556 (longest request)
    

    我正在使用PHP编写脚本。在进一步测试时,我还发现如果我从PHP脚本中注释MySQL连接部分,“失败请求”将变为0。怎么了?如何降低此故障率?

    谢谢你, 艾力

5 个答案:

答案 0 :(得分:7)

您预计会有100个并发请求吗?您希望在30秒内收到10K请求吗?

您可以运行此基准测试,但要问问自己这意味着什么。考虑一下您将接收的实际流量。你真的需要一个问题来反对:

  • 我希望我的网站有3,000名用户。
  • 我希望在高峰期使用时,其中500个会点击页面
  • 通常使用的是一分钟内的3个请求:3 * 500 / 60 = ~ 25 req/sec
  • 我的网站可以处理25 req / sec并做出响应(每次请求<200ms)吗?

除非您位于网络的前几个百分点,否则您的网页在现实生活中将不会看到100个并发请求。针对该流量级别调整您的网站没有意义。要获得这些数字,您需要在架构级别(数据库使用,缓存方法等)进行设计妥协:因此在数据库启动时您的失败次数。

如果您只想对自己的脚本进行分析,请使用xdebug查找代码花费时间的位置。

答案 1 :(得分:1)

我认为这看起来很棒。离开?我会说它超越常态。

一个问题是服务器上的负载将在生产中。您的脚本正在此服务器上触发请求,但如果您是开发实例上的唯一用户,则在处理典型生产负载时遇到生产服务器时会发生什么情况。

如果是这种情况,您需要两个请求来源:一个代表您的新应用,另一个代表生产流程,它将与资源竞争。

您可以在基准测试软件中设置同时用户数吗?这个测试是否只发送了1000个请求,一个接一个?让多个用户同时敲击服务器可能更为现实。

你可以随机发送发送间隔吗?这可能是您真实情况的更好表现。

您可以更改脚本使用的数据吗?它是否代表了它的使用条件非常好?

除此之外,我所能提供的只是祝贺。看起来你对我非常彻底。

答案 2 :(得分:1)

您不应该收到任何失败的请求 - 您需要检查错误日志以查看它们失败的原因。

最有可能的是MySQL连接耗尽,在这种情况下,您可以简单地调整服务器以允许更多的并发连接(如果您预计会有大量的流量)。

答案 3 :(得分:1)

尝试使用xdebug来分析您的代码。 xdebug也会为您提供更好的屏幕错误。堆栈痕迹。

然后使用webgrind以漂亮的格式查看个人资料。

答案 4 :(得分:0)

每个请求约200毫秒是一个有点常见的数字,对于大多数用户来说,页面看起来“快”。