2012-04-30 20 views
25

कुछ अजीब कारणों से, आज हमारे सर्वर ने सत्रों की शुरुआत के दौरान बहुत धीमी गति से निर्णय लेने का फैसला किया। प्रत्येक session_start के लिए, सर्वर 30 सेकंड के बाद या तो समय समाप्त हो जाता है, या सत्र शुरू करने में लगभग 20 सेकंड लगेंगे। यह बहुत अजीब है, क्योंकि यह बहुत लंबे समय तक ऐसा नहीं किया है (पिछली बार हमारे सर्वर ने लगभग 7 महीने पहले ऐसा किया था)। मैंने सत्र को डेटाबेस के माध्यम से चलाने के लिए बदलने की कोशिश की है, और यह ठीक काम करता है, हालांकि, हमारी वर्तमान वेबसाइट बनाई गई है, इसमें प्रत्येक पृष्ठ पर जाने के लिए दिन लगेंगे और नए सत्र को शामिल करने के लिए सत्रों को लोड करना होगा हैंडलर। इसलिए मेरा प्रश्न बनी हुई है:session_start बहुत धीमा प्रतीत होता है (लेकिन केवल कभी-कभी)

यह इतना धीमा क्यों है, और कभी-कभी क्यों?

हम 24 जीबी के रैम के साथ एक समर्पित हेट्ज़नर सर्वर पर चलते हैं, और एक सीपीयू बस एक साधारण वेबसर्वर चलाने के लिए पर्याप्त तेज़ (एक ज़ीओन, मुझे विश्वास है, लेकिन मुझे यकीन नहीं है)। हम एक apache + fastcgi + php5 सेटअप के साथ सर्वर पर डेबियन चलाते हैं।

सर्वर अधिक लोड की रिपोर्ट नहीं करता है, न तो सर्वर-स्थिति के साथ-साथ top कमांड के माध्यम से। Vnstat हमारे नेटवर्क लिंक के साथ कोई भी समस्या नहीं रिपोर्ट करता है (फिर से, जिसके परिणामस्वरूप धीमी स्थानीय सत्र हैंडलिंग नहीं होगी)। IOtop पूरे हार्डड्राइव को लेने वाली प्रक्रियाओं के साथ कोई समस्या नहीं रिपोर्ट करता है। Tmp फ़ोल्डर को लिखना जहां सत्र फ़ाइलें स्थित हैं, vim के माध्यम से किया जाता है तो तेज़ काम करता है।

फिर से, यह स्पष्ट करने के लिए, मेरी मुख्य चिंता यह नहीं है कि हमें डीबी या सत्रों के स्मृति-कैश संस्करण में स्विच करना चाहिए या नहीं, यह पूछने के लिए कि ऐसा क्यों होता है, क्योंकि मैं जो कुछ भी लेता हूं लगता है कि PHP के अलावा, ठीक काम कर रहा है।

EDIT: हमारी PHP tmp निर्देशिका में अधिकतम फ़ाइल 2.9 एमबी है, इसलिए कुछ भी नहीं जो प्रभाव डालना चाहिए, मुझे विश्वास है।

अद्यतन: मैंने कभी यह नहीं पता था कि क्या गलत था और/या इसे कैसे ठीक किया जाए, लेकिन जब हम memcached/db सत्रों पर स्विच करने के बाद समस्या गायब हो गई।

+2

अपनी 'tmp' निर्देशिका में एक नज़र डालें। PHP वहां अपने सत्र स्टोर करता है। देखें कि कुछ भी अस्वस्थ है या नहीं। – freshnode

+1

शायद डिस्क या फाइल सिस्टम के साथ कुछ गलत है? – Jon

+10

"प्रत्येक पृष्ठ पर जाने के लिए दिन लगेंगे और नए सत्र हैंडलर को शामिल करने के लिए सत्रों की लोडिंग को बदलना होगा" यदि ऐसा है तो आपको गंभीरता से उस तथ्य को ठीक करने पर विचार करना चाहिए – PeeHaa

उत्तर

14

क्या आपने session_write_close(); को आजमाया है? यह सत्र चर में लेखन क्षमता अक्षम कर देगा लेकिन आप अभी भी उनसे डेटा पढ़ सकते हैं। और बाद में जब आपको सत्र चर लिखना होगा, इसे फिर से खोलें।

मुझे भी इस समस्या से पीड़ित है लेकिन यह बात एक आकर्षण की तरह काम करती है।यह मुझे क्या करना है:

session_start(); //starts the session 
$_SESSION['user']="Me"; 
session_write_close(); // close write capability 
echo $_SESSION['user']; // you can still access it 
+0

धन्यवाद। मुझे कम से कम लगता है कि यह अब काम करता है। अभी तक बहुत तेज़ और कोई पूर्ण मंदी नहीं है :) –

0

प्रत्येक सत्र apache द्वारा टेक्स्ट फ़ाइल के रूप में संग्रहीत किया जाता है।

जब सत्र शुरू होता है तो मौजूदा सत्र को फिर से शुरू करने के लिए उपयोग किया जाता है (उदाहरण के लिए कुकी पहचानकर्ता के माध्यम से) शायद एक बड़ी सत्र फ़ाइल (अंदर बहुत सारी सामग्री वाला सत्र) शुरू किया जा सकता है?

यदि ऐसा है तो शायद यह मामला सत्रों में अधिक डेटा डाल रहा है।

+0

हमारे tmp फ़ोल्डर में सबसे बड़ी फ़ाइल 2.9 एमबी है, इसलिए कुछ भी नहीं जो _should_ प्रभाव डालता है। – h2ooooooo

1

मैं भी इस समस्या में भाग गया। यहां यह जवाब था:

Problem with function session_start() (works slowly)

सत्र जबकि एक स्क्रिप्ट पर कार्य कर रहा है PHP द्वारा बंद कर दिया जाता है, ताकि स्क्रिप्ट एक ही सत्र के तहत खड़ी कर रहे हैं, वे इन आश्चर्यजनक रूप से देर लग सकती है।

+0

मेरी इच्छा है कि यह बस इसे ठीक कर दे, लेकिन यह अजीब बात है कि यह साइट पर प्रत्येक उपयोगकर्ता (विभिन्न कंप्यूटरों पर हमारे कार्यालय से पहुंच सहित) के साथ कैसे हुआ, अगर यह केवल लॉक सत्र फ़ाइल है। शायद ऐसा इसलिए हो सकता है क्योंकि हमने टेक्स्ट फाइलों का उपयोग किया था, और इसलिए यह ** उसी ** फ़ाइल का उपयोग करता था, जिसे लॉक किया गया था? – h2ooooooo

4

मैं एक ही समस्या थी: अचानक सर्वर अनुरोध पर अमल करने के लिए 30 सेकंड लिया। मैंने देखा कि यह session_start() की वजह से था। पहला अनुरोध तेज था, लेकिन प्रत्येक अगले अनुरोध को निष्पादित करने के लिए कुछ 30 सेकंड लिया गया। मैंने पाया कि सी: \ wamp \ tmp में सत्र फ़ाइल कुछ 30 सेकंड के पहले अनुरोध द्वारा बंद कर दी गई थी। इस समय के दौरान दूसरा अनुरोध फ़ाइल को अनलॉक करने का इंतजार कर रहा था। मुझे पता चला कि इसमें rewrite_mod और .htaccess के साथ कुछ करना था। मैंने rewrite_mod को अक्षम कर दिया और .htaccess में प्रत्येक पंक्ति पर टिप्पणी की और यह एक आकर्षण की तरह फिर से काम करता है। मुझे नहीं पता कि यह क्यों खुश है क्योंकि मुझे याद नहीं है कि किसी भी सेटिंग्स को बदलना या वैंप पर भरोसा करना है।

+0

मैं पूरी तरह से इस समाधान के साथ सहमत हूं .. लेकिन मुझे क्यों नहीं पता। –

0

कृपया जांचें कि क्या आपके पास सही memcache सेटिंग्स उदा। /etc/php.d/memcached.ini

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