VBulletin टिप्पणियों या कैश गतिशील सामग्री के लिए प्रयास

मेरे अधिकार क्षेत्र में कई VPS हैं, जिन पर वह कताई कर रहा है ... सामान्य तौर पर, यह मेरी जिम्मेदारी का क्षेत्र नहीं है, और इसलिए यह वहां घूम रहा है, जो कताई कर रहा है, मध्यम रूप से धीमा हो रहा है, मध्यम रूप से काम कर रहा है। और यह पता चला कि एक मंच उनमें से एक पर घूम रहा था, और मंच धीमा होने लगा। और मैं यह पता लगाना चाहता था ...

Iskhdnye

• VBulletin 3.8.x के तहत फोरम
• Forum.domain.com सबडोमेन पर सबमिट किया गया
• नग्नेक्स 1.1.13, php 5.3.x (fpm)
• फोरम के अलावा, इस सर्वर पर कुछ भी नहीं घूम रहा है। ( यह महत्वपूर्ण है )।
• टीसीपी / आईपी पर एक अलग सर्वर पर मैसकल, संचार।

प्रागितिहास

एक मंच जीता, परेशान नहीं हुआ, 30-40 प्रतिशत के क्षेत्र में xm शीर्ष भार दिखाया। और फिर घंटा "एक्स" आया और भार ऊंची चोटियों के साथ 90 प्रतिशत के समतल शेल्फ में कूद गया, जो वास्तव में, गुलजार नहीं है। डीडीओएस के संदेह की पुष्टि नहीं की गई है। लॉग के अनुसार, सामान्य कार्यभार देखा गया था। ठीक है, संसाधनों में बेतहाशा वृद्धि से पहले, यह विचार उत्पन्न हुआ कि क्या हो रहा था और जो कुछ भी संभव था उसे कैश करने का प्रयास करें।

जांच। एक भाग - एक महिला आगंतुक क्या चाहती है

चूंकि मैं इस सॉफ़्टवेयर की विचारधारा और विशेषताओं से परिचित नहीं था, इसलिए मैंने आगंतुकों और सर्वर के बीच लॉग और ट्रैफ़िक के विश्लेषण के साथ समस्या का अध्ययन करना शुरू किया। सबसे पहले, मुझे यह जानकर आश्चर्य हुआ कि फोरम में संदेशों को अनुलग्नक विशेष रूप से अटैचमेंट . php स्क्रिप्ट द्वारा दिया जाता है, जबकि फाइलें स्वयं डेटाबेस में संग्रहीत की जा सकती हैं, वे स्थानीय डिस्क पर हो सकती हैं, लेकिन वापसी केवल स्क्रिप्ट के माध्यम से होती है। और कोई उपाय नहीं। यही है, हमें 8-10 फ़ोटोज़ के साथ प्रति संदेश शाखा php दुभाषिया के 8-10 अतिरिक्त जुड़वाँ मिलते हैं। और यह हर आगंतुक के लिए है। चूंकि इस फ़ोरम पर अटैचमेंट देखने के लिए पंजीकरण की आवश्यकता नहीं है, इसलिए अटैचमेंट को एक-दो दिनों के लिए कैश्ड किया जा सकता है। कुछ इस तरह:

location = /attachment.php { expires max; limit_req zone=lim_req_1s_zone burst=5; fastcgi_pass forum__php_cluster; include /etc/nginx/fastcgi_params; include /etc/nginx/fastcgi_params_php-fpm; fastcgi_cache forum_att__cache; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; fastcgi_hide_header Set-Cookie; fastcgi_hide_header Pragma; fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$host:$request_uri:"; fastcgi_cache_use_stale updating error timeout invalid_header http_500; fastcgi_cache_lock on; fastcgi_cache_lock_timeout 2m; fastcgi_cache_valid 2d; }  -  http-  forum_att__cache: fastcgi_cache_path /var/cache/nginx/att levels=1:2 keys_zone=forum_att__cache:4m max_size=2g inactive=2d; 

मेरे लिए दूसरा "रहस्योद्घाटन" यह था कि फोरम में अभिलेखागार हैं, और वे केवल मौजूद नहीं हैं, लेकिन लगभग आधे अनुरोध उनके द्वारा किए गए हैं। पृष्ठों की उपस्थिति भी आपको उनकी सामग्री को कैश करने की अनुमति देती है:

 location /archive/ { expires 10d; limit_req zone=lim_req_1s_zone burst=2; location ~ \.css$ { expires max; } fastcgi_pass forum__php_cluster; fastcgi_index index.php; include /etc/nginx/fastcgi_params; include /etc/nginx/fastcgi_params_php-fpm; fastcgi_param SCRIPT_FILENAME $document_root/archive/index.php; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_cache forum_arc__cache; fastcgi_hide_header Set-Cookie; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$host:$request_uri:"; fastcgi_cache_use_stale updating error timeout invalid_header http_500; fastcgi_cache_valid 2d; }   http-: fastcgi_cache_path /var/cache/nginx/arc levels=1:2 keys_zone=forum_arc__cache:4m max_size=2g inactive=2d;    DDOS-: limit_req_zone "$psUID" zone=lim_req_1s_zone:2m rate=1r/s; 

कुंजी "$ psUID" के गठन पर मैं आगे बताऊंगा।

जांच। भाग दो - vBulletin में प्राधिकरण

फोरम विजिटर के दृष्टिकोण से, दर्ज किया गया व्यक्ति या तो पंजीकृत उपयोगकर्ता या अतिथि हो सकता है। लेकिन एक पूरी तरह से अलग स्थिति पैदा होती है अगर हम ब्राउज़र में कुकीज़ के दिखने और गायब होने की स्थिति में "आया, चला गया, लॉग इन किया, चला गया, लॉग इन किया, चला गया" का अवलोकन करते हैं। तो, हम डोमेन और उसके उप डोमेन के लिए कुकीज़ को साफ़ करते हैं, HTTPfox खोलें और देखें कि क्या होता है:

 HTTP/1.1 200 OK Set-Cookie: PHPSESSID=cdme9rrptft67tbo97p4t1cua5; expires=Wed, 22-Feb-2012 15:04:12 GMT; path=/; domain=.domain.com Set-Cookie: bblastvisit=1329059052; expires=Mon, 11-Feb-2013 15:04:12 GMT; path=/; domain=.domain.com Set-Cookie: bblastactivity=0; expires=Mon, 11-Feb-2013 15:04:12 GMT; path=/; domain=.domain.com Set-Cookie: uid=XCuiGU831OyC8VLqAx/QAg==; expires=Thu, 31-Dec-37 23:55:55 GMT; domain=.domain.com; path=/ 

यूआईडी और PHPSESSID के साथ, सब कुछ स्पष्ट है - ये nginx और php दुभाषिया के साज़िश हैं। सत्र .auto_start विकल्प के साथ स्थापित किया गया है, लेकिन बाकी फ़ोरम पर गतिविधि अनुयायी हैं। लेकिन मुख्य सत्र कुकी vBulletin अभी तक नहीं देखा गया है। आगे देखते हुए, मैं कहता हूँ कि vBulletin मानक php-session का उपयोग नहीं करता है (अधिक सटीक रूप से, यह ALMOST इसका उपयोग नहीं करता है), लेकिन इसका स्वयं का नेतृत्व करता है, जिसकी पहचान bbsessionhash कुकी में संग्रहीत होती है। तो, उपयोगकर्ता ने लॉग इन किया है और कोई सत्र नहीं है - अर्थात, वह एक सत्र के बिना एक गुमनाम व्यक्ति है। इसके अलावा, मंच के लिंक दो रूप ले सकते हैं (मतलब पृष्ठ पर सभी लिंक, और न केवल एक, बल्कि अन्य):
forum.domain.com/forumdisplay.php?s=12b66e447be52ebc84ab16d3f39626fb&f=69
forum.domain.com/forumdisplay.php?f=69
और यदि आप पहले प्रकार के लिंक का पालन करते हैं, तो फ़ोरम से अगला उत्तर सत्र का कुकी होगा, लेकिन अगर दूसरे का लिंक नहीं है। यदि कुकी सत्र के दूसरे उत्तर के साथ नहीं आती है, तो आप तब तक सत्रावसान और बेचैन रह सकते हैं जब तक कि आप पहले प्रकार के लिंक में नहीं भागते (मैं उनके स्वरूप के पैटर्न की पहचान नहीं कर सका), या आप लॉग इन करना चाहते हैं। एक सफल लॉगिन के साथ, वैसे भी सत्र कुकी आ जाएगी। यदि अतिथि को लॉगिन करने से पहले एक अनाम सत्र था, तो सत्र को बदल दिया जाएगा। यह इस तरह दिखता है:

 HTTP/1.1 200 OK Set-Cookie: bbsessionhash=85745bc6110db5221e159087bf037f24; path=/; domain=.domain.com; HttpOnly 

लॉगिन के बाद, सत्र "स्थिर" है और लिंक के साथ छलांग नहीं लगती है। लॉगआउट प्रक्रिया मौलिकता में भिन्न नहीं होती है - सभी मौजूदा फ़ोरम कुकीज़ (यहां तक ​​कि जो सेट नहीं किए गए थे) हटा दी जाती हैं और एक नए ("अनाम") सत्र की कुकी लिखी जाती है:

 HTTP/1.1 200 OK Set-Cookie: bbsessionhash=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bblastvisit=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bblastactivity=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbthread_lastview=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbreferrerid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbuserid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbpassword=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbthreadedmode=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbstyleid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bblanguageid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbsessionhash=3d0bdc5dbe8dabae361deebe8f6048d2; path=/; domain=.domain.com; HttpOnly 

यही है, आउटपुट में हमें एक अनाम (अतिथि) मिलता है, लेकिन एक सत्र में सौ प्रतिशत।
नतीजतन, मंच सॉफ्टवेयर और HTTP हेडर के दृष्टिकोण से, हमारे पास तीन प्रकार के उपयोगकर्ता हैं: एक अतिथि के बिना एक सत्र , एक अतिथि के साथ एक अतिथि , एक लॉग-इन आगंतुक । इसके अलावा, नगीनक्स स्तर पर, दूसरे को तीसरे से अलग करना अत्यंत समस्याग्रस्त है।

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

 fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$host:$request_uri:$cookie_bbsessionhash:"; 

दोनों मेहमानों को संतुष्ट कर सकता है और उपयोगकर्ताओं में लॉग इन कर सकता है, हालांकि, व्यवहार में, आगंतुकों को किसी और के कैश की सामग्री प्राप्त करना शुरू हो गया। कैशिंग "सच" गतिशीलता को अक्षम करना पड़ा। मुझे उम्मीद है कि सजा अंतिम नहीं है।

हालाँकि, यह जानकारी बेकार नहीं है। इसके आधार पर, हम न केवल आगंतुक के आईपी पते पर, बल्कि उसकी स्थिति पर भी अनुरोधों की आवृत्ति को सीमित करने के लिए एक कुंजी उत्पन्न कर सकते हैं।

 set $psUID "anon"; set $psUCL "anon"; if ($cookie_bbsessionhash) { set $psUID "$cookie_bbsessionhash"; set $psUCL "user"; } if ($psUCL = "anon") { set $psUID "anon:$remote_addr"; } 

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

परिणाम

किए गए प्रयासों के परिणामस्वरूप, वर्चुअल मशीन पर कुल भार 90 प्रतिशत से कम होकर 40 से आरा तक हो गया और फटने के साथ 80 प्रतिशत हो गया।