सवाल अपाचे के लिए https बनाम http के लिए कितना प्रदर्शन मारा गया?


एक ही पृष्ठ के लिए https की तुलना में https की तुलना में कितना प्रदर्शन हिट होगा? मान लीजिए कि मैं abc.php के लिए 1000 अनुरोध / एस संभाल सकता हूं, https के माध्यम से एक्सेस होने पर यह कितना कम हो जाएगा? मुझे पता है कि यह हार्डवेयर, कॉन्फ़िगरेशन, ओएस आदि आदि पर निर्भर हो सकता है लेकिन मैं सिर्फ अंगूठे / अनुमान के सामान्य नियम की तलाश में हूं।


50
2017-07-21 18:45


मूल


+1 इसे पूछने के लिए धन्यवाद। :) - M.N
इसके लिए एक स्वीकार्य उत्तर देखना अच्छा लगेगा। - Hyppy


जवाब:


एक त्वरित और गंदे परीक्षण के लिए (यानी कोई अनुकूलन नहीं!) मैंने स्थानीय उबंटू 9.04 वीएम पर http और https (स्वयं हस्ताक्षरित प्रमाणपत्र) दोनों के साथ सरल उबंटू अपाचे 2 डिफ़ॉल्ट वेबसाइट (जो केवल "यह काम करता है!" सक्षम करता है) और अपाचे चलाया बेंचमार्क "ab"10,000 अनुरोध (कोई सहमति नहीं) के साथ। ग्राहक और सर्वर एक ही मशीन / वीएम पर थे:

का परिणाम एचटीटीपी ( "ab -n 10000 http://ubuntu904/index.html")

  • परीक्षण के लिए समय लिया गया: 2.664 सेकंड
  • प्रति सेकंड अनुरोध: 3753.6 9 (# / सेकंड)
  • प्रति अनुरोध समय: 0.266ms

का परिणाम https ( "ab -n 10000 https://ubuntu904/index.html"):

  • परीक्षण के लिए समय लिया गया: 107.673 सेकंड
  • अनुरोध प्रति सेकंड: 92.87 (# / सेकंड)
  • प्रति अनुरोध समय: 10.767ms

यदि आप टीसीपी / आईपी संचार पर एक नजदीक देखो (उदा। टीसीपीडम्प या वायरशर्क के साथ) लेते हैं एकल अनुरोध आप देखेंगे कि http केस को क्लाइंट और सर्वर के बीच 10 पैकेट की आवश्यकता होती है जबकि https को 16 की आवश्यकता होती है: https के साथ लेटेंसी बहुत अधिक है। (विलंबता के महत्व के बारे में अधिक यहाँ)

जीवित रहना (ab विकल्प -k) परीक्षण में स्थिति में सुधार होता है क्योंकि अब सभी अनुरोध एक ही कनेक्शन साझा करते हैं यानी एसएसएल ओवरहेड कम है - लेकिन https अभी भी मापने योग्य धीमा है:

का परिणाम एचटीटीपी जीवित रहने के साथ ("ab -k -n 10000 http://ubuntu904/index.html")

  • परीक्षण के लिए समय लिया गया: 1.200 सेकंड
  • अनुरोध प्रति सेकंड: 8334.86 (# / सेकंड)
  • प्रति अनुरोध समय: 0.120ms

का परिणाम https जीवित रहने के साथ ("ab -k -n 10000 https://ubuntu904/index.html"):

  • परीक्षण के लिए समय लिया गया: 2.711 सेकंड
  • अनुरोध प्रति सेकंड: 3688.12 (# / सेकंड)
  • प्रति अनुरोध समय: 0.271ms

निष्कर्ष:

  • इस सरल टेस्टकेस में https http से बहुत धीमी है।
  • Https समर्थन और बेंचमार्क सक्षम करना एक अच्छा विचार है आपका वेबसाइट यह देखने के लिए कि क्या आप https ओवरहेड के लिए भुगतान करना चाहते हैं।
  • एसएसएल ओवरहेड की छाप पाने के लिए वायरशर्क का प्रयोग करें।

57
2017-07-22 00:25



+1 वहां अच्छा काम है। संख्या पोस्ट करने के लिए धन्यवाद। - M.N
क्या हम उस मशीन के हार्डवेयर पर कुछ चश्मे प्राप्त कर सकते हैं? एन्क्रिप्शन प्रोसेसर शक्ति पर अत्यधिक निर्भर है। - Matt Simmons
मैंने हाल ही में एक वीपीएस पर बहुत सारे परीक्षण किए हैं और एकमात्र सबसे बड़ी चीज जिसने प्रदर्शन को प्रभावित किया था, सिफर का इस्तेमाल किया जा रहा था। यदि आप सिफर को 128 बिट तक सीमित करते हैं तो आपको एक सेकंड के बारे में 500-600 अनुरोध प्राप्त करने में सक्षम होना चाहिए। एक 256 बिट सिफर का उपयोग करना जो एक दूसरे को <100 अनुरोध करेगा। मेरा मानना ​​है कि जब मैंने अपना खुद का परीक्षण किया तो यह 30 सेकंड एक अनुरोध था। जाहिर है वास्तविक संख्या आपकी मशीन पर निर्भर करती है। - kovert
मैट सिमन्स, मैंने 2 कोर 64-बिट उबंटू 9.04 वीएम (वीएमवेयर फ़्यूज़न) का उपयोग 2008 के मैक प्रो पर 2x क्वाड-कोर 2.8 गीगाहर्ट्ज इंटेल ज़ीऑन सीपीयू के साथ किया था। - knweiss
आपके उत्तर ने मुझे एक प्रश्न पोस्ट करने से रोका है जो 20 सेकंड के भीतर बंद हो गया होता। धन्यवाद! - MonkeyZeus


आधुनिक सर्वर पर, मैं कहूंगा कि आपकी बाधा नेटवर्क और आपका एप्लीकेशन होगा, न कि एन्क्रिप्शन। अपाचे में टीएलएस / एसएसएल काफी अनुकूलित सी में लिखा जाएगा, इसलिए आपके PHP कोड द्वारा बौना किया जाएगा, खासकर यदि आप डेटाबेस एक्सेस जैसी चीजें करने जा रहे हैं। स्थैतिक फाइलों की सेवा करना शायद एक बड़ा प्रभाव होगा, क्योंकि एन्क्रिप्शन पूरी प्रक्रिया का एक बड़ा हिस्सा बन जाएगा। मैं आपको कोई ठोस आंकड़ा नहीं दे सकता, लेकिन मुझे आश्चर्य होगा कि यह 5% से अधिक था और शायद कुछ प्रतिशत के करीब था।


10
2017-07-21 18:53



डेविड सही है, यह आपकी तरह की सामग्री पर निर्भर करता है। अपाचे बैंच के साथ बेंचमार्क करना अच्छा तरीका होगा httpd.apache.org/docs/2.2/programs/ab.html - radius
एन्क्रिप्शन गति के अलावा, एसएसएल हैंडशेक के बारे में क्या, इसका सर्वर प्रदर्शन और थ्रूपुट पर कोई असर होगा? - erotsppa
एसएसएल हैंडशेक कनेक्शन के सामने कुछ पैकेट जोड़ देगा। इसका प्रभाव सर्वर और क्लाइंट के बीच कनेक्शन की विलंबता पर बड़े पैमाने पर निर्भर करेगा। HTTP रखरखाव इस हैंडशेकिंग के प्रभाव को कम करेगा। - David Pashley


कुछ भी मत मानो, इसे स्वयं परीक्षण करें! निश्चित रूप से अपने विशिष्ट वेब ऐप्स पर।


8
2017-07-21 22:04





मुझे लगता है कि आधुनिक हार्डवेयर पर, मैं प्रोसेसर (गणना) बाध्य होने की तुलना में किसी विशेष लेनदेन के लिए I / O बाध्य होने की अधिक संभावना है। संपीड़न और एन्क्रिप्शन के बारे में बात करते समय यह विशेष रूप से सच है। इन दिनों 128-बिट एन्क्रिप्शन छोटा है - मैं आम तौर पर एसएसएल का उपयोग कर आउटगोइंग पेजों को बहुत कठिन निर्माण और वितरित कर रहा हूं, और कुछ वर्षों में http और https ट्रैफ़िक के बीच प्रदर्शन में महत्वपूर्ण अंतर नहीं देखा है।


1
2017-07-21 19:08





मैं nginx के लिए सिफारिश दूसरी। अपने स्वयं के परीक्षणों में, यह एक समर्पित एसएसएल ऑफलोडर के रूप में अच्छी तरह से आयोजित किया गया है।


1
2017-07-22 10:23





बेशक अगर एसएसएल प्रसंस्करण कठिन हो जाता है, तो आप इसे हमेशा ऑफ-सर्वर को समर्पित बॉक्स में ले जा सकते हैं। Nginx over के साथ ऐसा करने के लिए एक अच्छा लिखना है यहाँ। यह कुछ है जो हमने अत्यधिक भारित परत 7 लोड संतुलित सर्वरों पर किया है।


0
2017-07-21 18:59





मैं पुष्टि कर सकता हूं कि एन्क्रिप्शन के लिए जोड़ा गया लोड शामिल हर दूसरे तत्व की तुलना में बहुत छोटा है (स्क्रिप्टिंग, नेटवर्क, ...)


0
2017-07-21 21:01





मेरे अनुभव से सामान्य नियम सीधे आपकी सार्वजनिक कुंजी कितनी बड़ी है (उदाहरण के लिए 2048, बनाम 40 9 6, बनाम 8192) सभी काफी महत्वपूर्ण हैं। हालांकि मुझे डेस्कटॉप वातावरण में शायद ही कोई फर्क पड़ता है, लेकिन मोबाइल वह जगह है जहां आप कंप्यूटिंग पावर लेते समय एक अंतर देखते हैं।

आम तौर पर यह दुर्भाग्यपूर्ण है लेकिन एसएसएल हमेशा रहता है और हमेशा एक बड़ा प्रदर्शन जुर्माना लेगा।


0
2018-04-18 22:15