2011-02-01 20 views
37

ठीक है, मैंने हर जगह खोज की है और मुझे अपाचे के एबी सर्वर बेंचमार्किंग टूल के परिणामों की व्याख्या करने के लिए ऑनलाइन विस्तृत संसाधन नहीं मिल रहा है। मैंने जो कुछ सोचा था, उसके साथ मैंने कई परीक्षण किए हैं, लेकिन मैंने बहुत ही समान परिणाम देखे हैं (मुझे मुश्किल समय लगता है कि इसका मतलब है कि मेरी साइट पूरी तरह से स्केल कर रही है!)। यदि कोई विस्तृत संसाधन है तो कोई मुझे इस बात से इंगित कर सकता है कि इस परीक्षा के परिणामों को कैसे समझें, या अगर कोई यहां एक बनाने जैसा महसूस करता है, तो मुझे लगता है कि यह मेरे और दूसरों के लिए बहुत उपयोगी होगा।अपाचे के एबी बेंचमार्किंग टूल से परिणामों की व्याख्या कैसे की जानी चाहिए?

उत्तर

28

निराशाजनक, है ना? मैं वही काम करने की कोशिश कर रहा हूं, देखें कि मेरा नया प्रावधान और कॉन्फ़िगर किया गया समर्पित सर्वर दूसरों से तुलना करता है।

जो मैं कर रहा हूं वह मेरे मौजूदा उत्पादन सर्वर (ड्यूल कोर 4 जीबी रैम) को नए सर्वर (क्वाड कोर 8 जीबी रैम) की तुलना कर रहा है।

मुझे उत्पादन की ओर से मेरी तरफ से 'अच्छा खेलना' है, क्योंकि उत्पादन सर्वर लाइव है और मैं अपने उपयोगकर्ताओं के लिए सर्वर को 'तोड़ना नहीं चाहता'।

एक php पृष्ठ है कि बस phpinfo कॉल पर की तुलना वर्तमान नए बनाम निम्न आदेश के साथ(): अब -kc 20 आयकर 60

मेरे वर्तमान उत्पादन सर्वर पर, मैं कुछ निम्नलिखित की तरह देखते हैं,

Time taken for tests: 60.1234 seconds 
Complete requests: 24538 
Failed requests: 58 
(Connect: 0, Length: 58, Exceptions: 0) 
Requests per second: 408.96 [#/sec] (mean) 
Time per request: 48.905 [ms] (mean) 
Time per request: 2.445 [ms] (mean, across all concurrent requests) 

नए सर्वर जो आधे समय के लिए राशि में सभी परीक्षण पूरा पर निम्नलिखित वी.एस.:

Time taken for tests: 29.838791 seconds 
Complete requests: 50000 
Failed requests: 11 
(Connect: 0, Length: 11, Exceptions: 0) 
Requests per second: 1675.67 [#/sec] (mean) 
Time per request: 11.936 [ms] (mean) 
Time per request: 0.597 [ms] (mean, across all concurrent requests) 
जहां यह समय के दिए गए राशि में कार्य को पूरा नहीं कर सका

अब, यह वास्तव में 'निष्पक्ष' परीक्षण नहीं है, क्योंकि वर्तमान सर्वर बेंचमार्क परीक्षण के अतिरिक्त 20 वेबसाइटों को संभालने वाला है। इसके अलावा, यह वास्तव में केवल apache & php का परीक्षण कर रहा है। वर्तमान सर्वर::

Time taken for tests: 60.14170 seconds 
Complete requests: 510 
Requests per second: 8.50 [#/sec] (mean) 
Time per request: 2353.497 [ms] (mean) 
Time per request: 117.675 [ms] (mean, across all concurrent requests) 

नई सर्वर:

मेरी और अधिक जटिल घर पृष्ठों में से एक के खिलाफ़ यही टेस्ट, एक लाना है कि 'लगता है' वर्तमान सर्वर पर धीमी गति से, मैं निम्न देखें

Time taken for tests: 60.18651 seconds 
Complete requests: 1974 
Requests per second: 32.89 [#/sec] (mean) 
Time per request: 608.092 [ms] (mean) 
Time per request: 30.405 [ms] (mean, across all concurrent requests) 

यह परीक्षण एक जूमला सीएमएस गतिशील रूप से जेनरेट किए गए पृष्ठ को लोड कर रहा है। यह एक 'असली दुनिया' परीक्षण का एक और अधिक है। फिर, नए सर्वर के साथ वर्तमान साइट यातायात से निपटने के साथ, तो यह सेब तुलना करने के लिए एक सेब नहीं है। मैं बहुत कठिन परीक्षण नहीं करना चाहता हूं या मैं अपनी साइट पर अपने अंतिम उपयोगकर्ता के अनुभव को जोखिम देता हूं।

साइट्स को नए सर्वर पर माइग्रेट करने के बाद, मैं उपरोक्त परीक्षणों को फिर से करने की योजना बना रहा हूं, इसलिए मैं देख सकता हूं कि मेरे नियमित साइट यातायात को बेंचमार्किंग पर क्या प्रभावित करता है। एक ही मशीन के उत्पादन बनाम निष्क्रिय बेंचमार्क परिणाम।

अब, मैं नए सर्वर पर जोर देने और यह सुनिश्चित करने के लिए भी देख रहा हूं कि यह अच्छी तरह से प्रतिक्रिया करता है। आदेश अब चल रहा है -n 50000 -c 200 मैं शीर्ष आदेश देख रहा हूँ और देख कितना सीपीयू & स्मृति का उपयोग किया जा रहा है जबकि यह भी * F5 * अपने ब्राउज़र में पेज ing अगर मैं किसी भी मिल को देखने के लिए त्रुटियों और यह भी महसूस करने के लिए कि सर्वर को जवाब देने में कितना समय लगता है।

Concurrency Level: 200 
Time taken for tests: 692.160011 seconds 
Complete requests: 50000 
Failed requests: 30102 
(Connect: 0, Length: 30102, Exceptions: 0) 
Write errors: 0 
Non-2xx responses: 30102 
Total transferred: 456568770 bytes 
HTML transferred: 442928962 bytes 
Requests per second: 72.24 [#/sec] (mean) 
Time per request: 2768.640 [ms] (mean) 
Time per request: 13.843 [ms] (mean, across all concurrent requests) 
Transfer rate: 644.17 [Kbytes/sec] received 

नोट बहुत ही उच्च असफल अनुरोध दर:

मेरा पहला परीक्षण मुझे दिया। मेरा अपाचे अधिकतम 250 एक साथ अनुरोधों पर सेट है, लेकिन मेरा MySQL केवल 175 पर था। MySQL यहां विफलता बिंदु था। यह अपाचे से आने वाले सभी अनुरोधों को संसाधित नहीं कर सका। मेरे वेब ब्राउज़र पेज लोड मुझे कई पेज रीफ्रेश पर एक MySQL कनेक्शन त्रुटि पृष्ठ दे रहा था।

तो, मैंने माईएसक्यूएल को 300 एक साथ अनुरोधों पर चढ़ाया (मैंने इसे पहले ही किया था, लेकिन माईएसक्यूएल को पुनरारंभ करना भूल गया था, इसलिए यह एक अच्छा परीक्षण साबित हुआ - मैंने एक आवश्यक परिवर्तन की पहचान की थी, और गलती से एक अनुभवजन्य किया परिवर्तन की आवश्यकता को प्रमाणित करने का परीक्षण)।

अगले रन मुझे दिया निम्नलिखित परिणाम:

Concurrency Level:  200 
Time taken for tests: 1399.999463 seconds 
Complete requests:  50000 
Failed requests:  5054 
    (Connect: 0, Length: 5054, Exceptions: 0) 
Write errors:   0 
Non-2xx responses:  5054 
Total transferred:  1016767290 bytes 
HTML transferred:  995713274 bytes 
Requests per second: 35.71 [#/sec] (mean) 
Time per request:  5599.998 [ms] (mean) 
Time per request:  28.000 [ms] (mean, across all concurrent requests) 
Transfer rate:   709.24 [Kbytes/sec] received 

इस से अधिक दो बार के रूप में बहुत समय लगा, लेकिन असफल अनुरोध दर बहुत बहुत कम थी। असल में, सर्वर अब मेरी साइट के होम पेज में से एक के कम से कम 200 एक साथ पृष्ठ दृश्यों को संभालने में सक्षम होने के लिए कॉन्फ़िगर किया गया है, लेकिन उन्हें सेवा देने के लिए 5 सेकंड का समय लगेगा। अच्छा नहीं है, लेकिन MySQL त्रुटियों से काफी बेहतर है जो मैं पहले प्राप्त कर रहा था।

इस सब के दौरान, मेरा सर्वर सीपीयू उपयोग 180% से ऊपर होवर 'भार औसत' के साथ 100% पर आ रहा है। MySQL CPU के लगभग 8-9% का उपयोग कर रहा है और मैं रैम का अधिक उपयोग नहीं कर रहा हूं। मैंने इसे आवंटित किया है, क्योंकि मैं बार-बार एक ही पृष्ठ पर हमला कर रहा हूं, इसलिए यह केवल एक डेटाबेस से निपट रहा है। 4 जीबी का 400 एमबी + इसे विकसित करने के लिए कॉन्फ़िगर किया गया है। शीर्ष कुल उपलब्ध रैम के लगभग 50% पर बफर और कैश मेमोरी उपयोग दिखाता है। इसलिए जब मैं इस परीक्षण के साथ मशीन को लोड कर रहा हूं, तो यह ओवरलोडेड पॉइंट के पास नहीं जा रहा है। वास्तविक दुनिया डेटाबेस उपयोग के तहत, MySQL को उस स्मृति को अधिकतर लेना चाहिए जिसे मैंने आवंटित किया है, इसलिए सर्वर उस बिंदु पर पूर्ण लोड के करीब होना चाहिए।

मेरा अगला परीक्षण 250 कनेक्शनों की 'पूरा भार' अब 50000 -n -c 250

Concurrency Level:  250 
Time taken for tests: 1442.515514 seconds 
Complete requests:  50000 
Failed requests:  3509 
    (Connect: 0, Length: 3509, Exceptions: 0) 
Write errors:   0 
Non-2xx responses:  3509 
Total transferred:  1051321215 bytes 
HTML transferred:  1029809879 bytes 
Requests per second: 34.66 [#/sec] (mean) 
Time per request:  7212.577 [ms] (mean) 
Time per request:  28.850 [ms] (mean, across all concurrent requests) 
Transfer rate:   711.73 [Kbytes/sec] received 

यह उचित MySQL के साथ 200 कनेक्शन परीक्षण करने के लिए इसी तरह के परिणाम दिखा रहा है पर अपाचे परीक्षण करने के लिए था कनेक्शन टोपी मुझे लगता है कि यह मेरे लिए अच्छा है। मुझे पृष्ठ वापस करने के लिए 7 सेकंड पसंद नहीं हैं, लेकिन मुझे लगता है कि मैं जूमला में कैशिंग को एपीसी या मेमकैच के साथ कैशिंग सक्षम करके जूमला स्तर पर सुधार कर सकता हूं जो दोनों स्थापित हैं लेकिन अभी तक जूमला द्वारा उपयोग नहीं किए जाते हैं।

मेरी किस्मत को धक्का देने की कोशिश करते हुए, मैंने सोचा कि मैं 300 एक साथ कनेक्शन का प्रयास करूंगा। ab -n 50000 -c 300 ब्राउज़र त्वरित पृष्ठ लोड के लिए एक लंबा इंतजार दिखाता है। अन्यथा, परिणामों में वास्तव में बहुत अधिक परिवर्तन नहीं है।

Concurrency Level:  300 
Time taken for tests: 1478.35890 seconds 
Complete requests:  50000 
Failed requests:  2266 
    (Connect: 0, Length: 2266, Exceptions: 0) 
Write errors:   0 
Non-2xx responses:  2266 
Total transferred:  1079120910 bytes 
HTML transferred:  1057241646 bytes 
Requests per second: 33.83 [#/sec] (mean) 
Time per request:  8868.215 [ms] (mean) 
Time per request:  29.561 [ms] (mean, across all concurrent requests) 
Transfer rate:   712.99 [Kbytes/sec] received 

मैं अगर इन परिणामों की मेरी व्याख्या 'सही' कर रहे हैं या अगर मैं कुछ मूल्यवान याद आ रही है पता नहीं है, लेकिन शिक्षा है कि मैं मिल सकता है की कमी के साथ, यह क्या मैं के साथ आया है।

मैंने यह सुनिश्चित करने के लिए परिणामों का उपयोग किया कि मुझे एक अच्छी प्रतिक्रिया दर मिली है - एक सही प्रतिक्रिया दर की कमी मुझे चिंतित करती है, लेकिन मुझे नहीं पता कि विफलताओं को कैसे देखना या पुन: पेश करना है, जिस तरह से मैं उनका निरीक्षण कर सकता हूं ।

प्रति अनुरोध धीमा समय मुझे भी चिंतित करता है, लेकिन मुझे लगता है कि मैं इसे एप्लिकेशन परत पर अधिक से अधिक संबोधित कर सकता हूं।

मुझे विश्वास है कि सर्वर क्रॉल में धीमा हो जाएगा, यह भारी लोड स्थिति को संभालने में सक्षम हो सकता है।

इन बेंचमार्किंग परीक्षणों के बाद मुझे मॉनियोग जैसे अन्य प्रदर्शन ट्यूनिंग टूल को देखकर मुझे यह भी दिखाया गया है कि मेरी वर्तमान कॉन्फ़िगरेशन 'पर्याप्त अच्छी' हैं।

मेरी इच्छा है कि वहां एक ऐसी जगह थी जहां लोगों ने परीक्षण के परिणाम पोस्ट किए हैं, मैं हार्डवेयर विवरण और सॉफ़्टवेयर कॉन्फ़िगरेशन के साथ पुन: उत्पन्न कर सकता हूं, इसलिए मुझे पता है कि मैं 'प्रतिस्पर्धी' हूं या यदि मेरे पास अभी तक सबसे अच्छा उपयोग करने के लिए बहुत सारे काम हैं मेरे उपकरण इस प्रकार, मैं अपने परिणाम क्यों पोस्ट कर रहा हूं।

+2

मुझे लगता है कि आप असफल अनुरोध लाइन का गलत व्याख्या कर रहे हैं, मेरा उत्तर भी देखें। – amarillion

+0

स्पष्टीकरण amarillion – creuzerm

+0

के लिए धन्यवाद क्या आप स्थानीय मशीन पर परीक्षण कर रहे हैं? हां - आप उसी मशीन पर एबी कर रहे हैं जहां वेब सर्वर है। जब मैं अपने कंप्यूटर पर अपाचे बेंचमार्क करता हूं तो मुझे केवल प्रति सेकंड 1k से अधिक अनुरोध मिलते हैं। – David

8

कृपया ध्यान दें कि "विफल अनुरोध" लाइन के लिए, एक असफल अनुरोध एक दूसरे के खिलाफ अनुवर्ती अनुरोधों की लंबाई की तुलना करके निर्धारित किया जाता है। गतिशील वेबसाइट के लिए, इसका मतलब यह नहीं है कि अनुरोध बिल्कुल असफल रहा! तो असफल अनुरोध लाइन के बारे में चिंता न करें।

यह भी देखें: http://www.celebrazio.net/tech/unix/apache_bench.html

1

एक तरफ ध्यान दें पर, एबी एकल पिरोया (जो 2001 पेंटियम 4 जैसे पुराने एकल-कोर सीपीयू के लिए ठीक है) है।

एक वेब-सर्वर होस्ट करने वाले बहु-कोर CPU का परीक्षण करने के लिए (कई प्रक्रियाओं का उपयोग करके Nginx/लाइटी, कई धागे का उपयोग करके अपाचे), आपको वेटटैप (जो एबी के साथ संगत है) का उपयोग करना चाहिए।

"वेट्टीपी -6" 6 क्लाइंट थ्रेड चलाएगा (इसके विपरीत "एबी -टी 6" 6-सेकेंड टेस्ट चलाएगा)।

आपको कई क्लाइंट थ्रेड्स (जितना अधिक वेबसर्वर श्रमिकों की संख्या - सर्वर सर्वर के सीपीयू कोर की संख्या से मेल खाना चाहिए) का उपयोग करके अधिक प्रासंगिक परिणाम मिलेंगे।

+5

अब आपको समवर्ती स्तर निर्दिष्ट करने की अनुमति देता है। मुझे लगता है कि इसका मतलब है कि यह बहु-थ्रेडेड है, इस अर्थ में आप यहां उपयोग कर रहे हैं। जैसे ab -n 1000 -c 10 http: // myserver/ 10 समवर्ती अनुरोधकर्ताओं से 100 अनुरोध चलाएगा, जिसमें कुल मिलाकर 1000 हिट होंगे। –

1
Time per request:  7.303 [ms] (mean) 
Time per request:  0.730 [ms] (mean, across all concurrent requests) 

पहले एक समवर्ती उपयोगकर्ताओं प्रति अनुरोध के लिए औसत समय से संबंधित है के बीच अंतर के बारे में अधिक के संबंध के साथ एक बहुत अच्छा संबंध है इसलिए यदि आप 1000 अनुरोधों और 200 समवर्ती उपयोगकर्ताओं के लिए परीक्षण कर रहे हैं, तो पहला 200 अनुरोध प्रत्येक के लिए औसत समय होगा। दूसरा अनुरोध कुल अनुरोध समय से संबंधित है जो पूरे 1000 अनुरोधों पर औसत समय

संबंधित मुद्दे