效率，基準測試，速度測試，性能

我正在嘗試編寫一個腳本，其效率我正在測量。我有幾個問題： -效率，基準測試，速度測試，性能

對於小型應用程序，是否需要這種類型的分析？還是我越來越偏執？（假設大多數代碼效率很高/沒有無限循環）
針對我該做什麼基準測試？我應該比較什麼？
以下是我從ab獲得的效率輸出。這種方式太離譜了嗎？我是否正在設計這款應用的方向錯誤？有沒有我應該注意的警告信號？

 
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。怎麼了？我如何減少這種故障率？

謝謝亞歷克

來源

2009-01-28 Alec Smart

您是否期望100個併發請求？你希望在30秒內收到10K的請求嗎？

你可以運行這個基準測試是很棒的，但問問你自己是什麼意思。考慮你將會收到的真正的流量。你真的需要一個基準的問題：

我希望我的網站將有3,000個用戶。
我希望在使用高峯期，他們中的500將打在頁面
一個典型的用法是過了一分鐘3個請求：3 * 500/60 = ~ 25 req/sec
可以在我的網站處理25請求/秒和響應（< 200ms的每請求）？

除非您處於網絡的前幾個百分比，否則您的網頁在現實生活中將看不到100個併發請求。調整您的網站達到該級別的流量是沒有意義的。要達到這些數字，您需要在架構級別進行設計折衷（數據庫使用率，緩存方法等），因此您需要在數據庫運行時發生故障次數。

如果您只是試圖分析腳本，請使用xdebug來查找您的代碼花費的時間。

來源

2009-01-28 16:08:35

我想，這看起來像一個偉大的工作。離開？我會說它超出了常態。

一個問題是服務器上的負載將在生產中。您的腳本在此服務器上觸發請求，但如果您是開發實例中的唯一用戶，則在處理典型的生產負載時，您看不到生產服務器上會發生什麼情況。

如果是這種情況，您需要兩個請求源：一個代表您的新應用程序，另一個代表與您的資源競爭的生產流程。

您可以在基準軟件中設置同時使用的用戶數量嗎？這個測試是否一次發送1000個請求？讓多個用戶同時在服務器上激活可能會更現實。

你可以使發送間隔是隨機的嗎？這可能是您真實情況的更好表現。

你可以改變腳本使用的數據嗎？它代表了它將被很好地使用的條件嗎？

除此之外，我所能提供的只是我的祝賀。看起來你對我很透徹。

來源

2009-01-28 12:08:51 duffymo

〜每個請求200毫秒是一個有點常見的數字，在這個數字中，大多數用戶的頁面似乎是「快速」的。

來源

2009-01-28 12:20:45 Karsten

你不應該得到任何失敗的請求 - 你需要檢查你的錯誤日誌，看看他們爲什麼失敗。

這很可能是MySQL用完了連接，在這種情況下，您可以簡單地調整您的服務器以允許更多併發連接（如果您期望流量）。

來源

2009-01-28 12:25:50 Greg

嘗試使用xdebug來分析您的代碼。 xdebug也會給你更好的屏幕錯誤&堆棧跟蹤。

然後使用webgrind以良好格式查看配置文件。

來源

2009-01-28 15:12:47

效率，基準測試，速度測試，性能

回答

相關問題