Python Web服務(wù)器并發(fā)性能測(cè)試
測(cè)試條件
- 測(cè)試機(jī)器：四核，4GB內(nèi)存
- 系統(tǒng)環(huán)境：Ubuntu 14.04 LTS
- 測(cè)試環(huán)境：django
- 測(cè)試工具：apache ab
- 測(cè)試參數(shù)：1000個(gè)并發(fā) 1000~10000個(gè)請(qǐng)求
測(cè)試效果
- django
毫無疑問，用原生django的server做處理的表現(xiàn)是最爛的，在10000次請(qǐng)求的情況下brokenpipe的幾率極高，只有1400次請(qǐng)求被處理，成功率只有14%，我也懶得繼續(xù)測(cè)下去了。 - django + nginx
這次搭上了nginx做反向代理，也使的脆弱的django服務(wù)器的情況有所緩解，但成功率仍然不高（10000次請(qǐng)求中有3684個(gè)請(qǐng)求被處理）。 - uwsgi + nginx
uwsgi是性能極高的一個(gè)由C編寫的服務(wù)器，它使用uwsgi協(xié)議，這次讓它配合nginx處理django的request，參數(shù)為4進(jìn)程+2線程，性能立即直線上升，處理請(qǐng)求的成功率也基本在90%左右，不過我在測(cè)試時(shí)遇到了一個(gè)坑，就是uwsgi在處理請(qǐng)求的時(shí)候發(fā)送了隊(duì)列溢出的問題，因?yàn)楫?dāng)前測(cè)試設(shè)置的并發(fā)數(shù)為每秒1000次并發(fā)，而uwsgi的處理隊(duì)列容量默認(rèn)為100，導(dǎo)致處理請(qǐng)求的時(shí)間加長(zhǎng)，而這個(gè)問題則可以通過修改somaxcon的大小解決，總的來說，使用uwsgi+nginx是一個(gè)理想的選擇。 - gunicorn + nginx
gunicorn跟uwsgi類似，也是一個(gè)高性能的http服務(wù)器，它由ruby的unicorn項(xiàng)目移植，是由python編寫的，它的配置簡(jiǎn)單，而且可以靈活地搭配其他網(wǎng)絡(luò)庫(kù)，部署十分方便，在測(cè)試數(shù)據(jù)中可以看到，用這種配置運(yùn)行django能在短時(shí)間內(nèi)就能處理大量的并發(fā)請(qǐng)求，成功率在90%左右。 - gunicorn + nginx + gevent
前面說的幾種環(huán)境，看似不錯(cuò)，但我們需要追求完美！由于gunicorn是同步（sync）單線程模型的，有的時(shí)候它不免會(huì)發(fā)生一些阻塞問題，這時(shí)候我們?yōu)間unicorn加上-k gevent參數(shù)來用gevent做處理接口，這就比較靠譜地處理了阻塞問題，從數(shù)據(jù)中可以看到，gunicorn + nginx + gevent的模式不僅擁有100%的處理成功率，而且時(shí)間也在很短之內(nèi)完成，是5組測(cè)試數(shù)據(jù)當(dāng)中的性能最好的。
每秒發(fā)送1000次并發(fā)需要時(shí)間
1.png
每秒發(fā)送1000次并發(fā)有效請(qǐng)求
2.png
所有測(cè)試數(shù)據(jù)
3.png
