गति और स्केलेबिलिटी के लिए कोहना-आधारित वेबसाइटों का अनुकूलन

Question

एक साइट जिसे मैंने कोहना के साथ बनाया था, कल भारी मात्रा में ट्रैफ़िक के साथ पटक दिया गया था, जिससे मुझे एक कदम पीछे हटना पड़ा और कुछ डिज़ाइन का मूल्यांकन करना पड़ा। मैं उत्सुक हूं कि कोहना-आधारित अनुप्रयोगों के अनुकूलन के लिए कुछ मानक तकनीकें क्या हैं?

मुझे बेंचमार्किंग में भी दिलचस्पी है। क्या मुझे सभी पृष्ठों के लिए निष्पादन समय देखने के लिए सेटअप करने की आवश्यकता है Benchmark::start()और Benchmark::stop()प्रत्येक नियंत्रक-विधि के लिए, या क्या मैं विश्व स्तर पर और जल्दी से बेंचमार्किंग लागू करने में सक्षम हूं?

मैं आने वाले समय में अधिक कैशे-लाइब्रेरी का उपयोग करूंगा, लेकिन मैं अधिक सुझावों के लिए खुला हूं क्योंकि मुझे यकीन है कि बहुत कुछ है जो मैं कर सकता हूं कि मैं इस समय केवल जागरूक नहीं हूं।

Comments

क्या आपने आवेदन की कुछ जानकारी प्राप्त करने के लिए कोहन प्रोफिलर में निर्माण की कोशिश की? यह काफी अच्छा है

— यासन झेलेव

Answer 1

इस उत्तर में मैं जो कहूंगा वह कोहना के लिए विशिष्ट नहीं है, और संभवतः बहुत सारी PHP परियोजनाओं पर लागू हो सकता है।

यहां कुछ बिंदु हैं जो प्रदर्शन, मापनीयता, पीएचपी के बारे में बात करते समय मेरे दिमाग में आते हैं, ...
मैंने कई परियोजनाओं पर काम करते समय उन विचारों में से कई का उपयोग किया है - और उन्होंने मदद की; इसलिए वे शायद यहाँ भी मदद कर सकते थे।

सबसे पहले, जब प्रदर्शन की बात आती है, तो कई पहलू / प्रश्न हैं जिन पर विचार करना है :

• सर्वर का विन्यास (अपाचे, पीएचपी, माईएसक्यूएल, अन्य संभावित डेमॉन और सिस्टम) ; आप के बारे में अधिक मदद मिल सकती है कि ServerFault पर , मुझे लगता है,
• PHP कोड,
• डेटाबेस प्रश्न,
• अपने वेबसर्वर का उपयोग करना या नहीं करना?
• क्या आप किसी भी प्रकार के कैशिंग तंत्र का उपयोग कर सकते हैं? या क्या आपको हमेशा वेबसाइट पर डेटा अप करने की आवश्यकता है?

रिवर्स प्रॉक्सी का उपयोग करना

पहली चीज़ जो वास्तव में उपयोगी हो सकती है , अपने वेबसर्वर के सामने वार्निश की तरह, एक रिवर्स प्रॉक्सी का उपयोग कर रही है : इसे जितना संभव हो उतना कैश दें , इसलिए केवल अनुरोधों की आवश्यकता है कि PHP / MySQL गणना (और, निश्चित रूप से, कुछ अन्य) अनुरोध, जब वे प्रॉक्सी के कैश में नहीं हैं) अपाचे / PHP / MySQL के लिए बनाते हैं।

• सबसे पहले, आपके CSS / Javascript / Images - ठीक है, सब कुछ जो स्थिर है - शायद Apache द्वारा हमेशा सेवा करने की आवश्यकता नहीं है
  • तो, आप उन सभी के विपरीत रिवर्स कैश कर सकते हैं।
  • उन स्टैटिक फ़ाइलों की सेवा करना अपाचे के लिए कोई बड़ी बात नहीं है, लेकिन इसके लिए जितना कम काम करना होगा, उतना ही यह PHP के लिए करने में सक्षम होगा।
  • याद रखें: अपाचे एक समय में सीमित, सीमित अनुरोधों की संख्या को ही सर्वर कर सकता है।
• फिर, रिवर्स प्रॉक्सी को कैश से जितना संभव हो उतना PHP- पृष्ठ परोसें: संभवत: कुछ पृष्ठ ऐसे हैं जो अक्सर बदलते नहीं हैं , और कैश से परोसे जा सकते हैं। कुछ PHP-आधारित कैश का उपयोग करने के बजाय, दूसरे, लाइटर, सर्वर को क्यों न दें (और उन्हें समय-समय पर PHP सर्वर से प्राप्त करें, इसलिए वे हमेशा अद्यतित होते हैं) ?
  • उदाहरण के लिए, यदि आपके पास कुछ RSS फ़ीड्स हैं (हम आम तौर पर उन लोगों को भूल जाते हैं, जब प्रदर्शन के लिए अनुकूलन करने की कोशिश करते हैं ) जो बहुत बार अनुरोध किए जाते हैं , तो कुछ मिनटों के लिए कैश में होने से Apache + PHP के लिए सैकड़ों / हजारों अनुरोध बच सकते हैं + MySQL!
  • आपकी साइट के सबसे अधिक देखे गए पृष्ठों के लिए भी, यदि वे कम से कम कुछ मिनटों के लिए नहीं बदलते हैं (उदाहरण: मुखपृष्ठ?) , तो, सीपीयू को बर्बाद करने की आवश्यकता नहीं है, प्रत्येक बार जब कोई उपयोगकर्ता उनसे अनुरोध करता है।
• हो सकता है कि वहाँ गुमनाम उपयोगकर्ताओं के लिए कार्य किया पृष्ठों के बीच एक अंतर है (सभी अनाम उपयोगकर्ताओं के लिए एक ही पृष्ठ) और पृष्ठों की पहचान उपयोगकर्ताओं के लिए कार्य किया (उदाहरण के लिए, "नमस्ते श्री एक्स, आपको नए संदेश प्राप्त") ?
  • यदि ऐसा है, तो आप संभवतः रिवर्स प्रॉक्सी को उस पेज को कैश करने के लिए कॉन्फ़िगर कर सकते हैं जो गुमनाम उपयोगकर्ताओं (कुकी के आधार पर, सत्र कुकी की तरह, आमतौर पर) के लिए परोसा जाता है।
  • इसका मतलब यह होगा कि अपाचे + पीएचपी के साथ सौदा करने के लिए कम है: केवल पहचाने गए उपयोगकर्ता - जो आपके उपयोगकर्ताओं का केवल एक छोटा हिस्सा हो सकते हैं।

कैश के रूप में रिवर्स-प्रॉक्सी का उपयोग करने के बारे में , PHP एप्लिकेशन के लिए, आप, उदाहरण के लिए, बेंचमार्क परिणामों पर एक नज़र डाल सकते हैं, एपीसी और स्क्वीड कैश के साथ सर्वर क्षमताओं में 400% -700% वृद्धि दिखाएं ।
(हां, वे स्क्वीड का उपयोग कर रहे हैं, और मैं वार्निश के बारे में बात कर रहा था - यह सिर्फ एक और संभावना है ^ ^ वार्निश अधिक हाल ही में, लेकिन कैशिंग के लिए अधिक समर्पित है)

यदि आप इतनी अच्छी तरह से करते हैं, और बार-बार बहुत सारे पृष्ठों को फिर से बनाने से रोकने का प्रबंधन करते हैं, तो शायद आपको अपने कोड का अनुकूलन भी नहीं करना होगा ;-)
कम से कम, शायद किसी भी तरह की जल्दबाजी में नहीं ... और यह हमेशा बेहतर होता है कि जब आप बहुत अधिक प्रेस् टर न हों तो ऑप्टिमाइज़ेशन करें ...

एक विचार के रूप में: आप ओपी में कह रहे हैं:

एक साइट जिसे मैंने कोहना के साथ बनाया था, कल भारी मात्रा में यातायात के साथ पटक दिया गया था,

यह एक तरह की अचानक स्थिति है जहां एक रिवर्स-प्रॉक्सी सचमुच दिन बचा सकता है , अगर आपकी वेबसाइट दूसरी तारीख तक नहीं होने से निपट सकती है:

• इसे स्थापित करें, इसे कॉन्फ़िगर करें, इसे हमेशा रहने दें - हर सामान्य दिन - रन:
  • PHP पृष्ठों को कैश में न रखने के लिए इसे कॉन्फ़िगर करें; या केवल एक छोटी अवधि के लिए; इस तरह, आपके पास हमेशा प्रदर्शित डेटा अप टू डेट होता है
• और, जिस दिन आप स्लैशडॉट या डिग प्रभाव लेते हैं:
  • PHP पृष्ठों को कैश में रखने के लिए रिवर्स प्रॉक्सी कॉन्फ़िगर करें; या लंबी अवधि के लिए; हो सकता है कि आपके पृष्ठ दूसरे तक अद्यतित न हों, लेकिन यह आपकी वेबसाइट को डिग-प्रभाव से बचे रहने देगा!

उसके बारे में, मैं कैसे "स्लैशडॉट" का पता लगा सकता हूं और जीवित रह सकता हूं? एक दिलचस्प पढ़ा जा सकता है।

चीजों की PHP की ओर:

सबसे पहले: क्या आप PHP के हालिया संस्करण का उपयोग कर रहे हैं ? नए संस्करणों के साथ गति में नियमित रूप से सुधार होते हैं ;-)
उदाहरण के लिए, 5.3-CVS के माध्यम से PHP शाखाओं 3.0 की बेंचमार्क पर एक नज़र डालें ।

ध्यान दें कि प्रदर्शन PHP 5.3 का उपयोग करने के लिए काफी अच्छा कारण है ( मैंने कुछ बेंचमार्क (फ्रेंच में) बनाया है , और परिणाम बहुत अच्छे हैं ) ...
एक और बहुत अच्छा कारण है, निश्चित रूप से, कि PHP 5.2 जीवन के अंत तक पहुंच गया है , और अब बनाए नहीं रखा है!

क्या आप किसी भी ओपेक कैश का उपयोग कर रहे हैं?

• मैं एपीसी के बारे में सोच रहा हूं - वैकल्पिक पीएचपी कैश , उदाहरण के लिए ( पीईसीएल , मैनुअल ) , जो कि मैंने देखा है वह समाधान है - और इसका उपयोग उन सभी सर्वरों पर किया जाता है जिन पर मैंने काम किया है।
  • इसे भी देखें: स्लाइड्स में APC फेसबुक ,
  • या बेंचमार्क परिणाम एपीसी और स्क्वीड कैश के साथ सर्वर क्षमताओं में 400% -700% वृद्धि दिखाते हैं ।
• यह वास्तव में सर्वर के सीपीयू-लोड को बहुत कम कर सकता है, कुछ मामलों में (मैंने देखा है कि कुछ सर्वरों पर सीपीयू-लोड 80% से 40% तक जाता है, बस एपीसी स्थापित करके और यह ओपोड-कैश कार्यक्षमता को सक्रिय करता है!)
• मूल रूप से, PHP स्क्रिप्ट का निष्पादन दो चरणों में होता है:
  • PHP स्रोत-कोड का ऑपकोड्स के संकलन (JAVA के बायटेकोड के बराबर)
  • उन opcodes का निष्पादन
  • एपीसी उन लोगों को स्मृति में रखता है, इसलिए हर बार पीएचपी स्क्रिप्ट / फ़ाइल निष्पादित होने पर कम काम होता है: केवल रैम से ऑपकोड प्राप्त करें, और उन्हें निष्पादित करें।
• आप पर एक नज़र लेने के लिए आवश्यकता हो सकती है एपीसी के कॉन्फ़िगरेशन विकल्प , वैसे
  • उनमें से काफी कुछ हैं, और कुछ आपके लिए गति / सीपीयू-लोड / उपयोग में आसानी दोनों पर बहुत प्रभाव डाल सकते हैं
  • उदाहरण के लिए, अक्षम करना [apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat)सिस्टम-लोड के लिए अच्छा हो सकता है; लेकिन इसका मतलब है कि PHP फ़ाइलों में किए गए संशोधनों को ध्यान में नहीं रखा जाएगा जब तक कि आप पूरे ओपेक-कैश को फ्लश नहीं करते हैं; इसके बारे में, अधिक विवरण के लिए, उदाहरण के लिए स्टेट () या स्टेट टू नॉट () देखें?

डेटा के लिए कैश का उपयोग करना

जितना संभव हो, एक ही चीज को बार-बार करने से बचना बेहतर है ।

मुख्य बात जो मैं सोच रहा हूं, निश्चित रूप से, SQL क्वेरी: आपके कई पृष्ठ संभवतः एक ही प्रश्न करते हैं, और उनमें से कुछ के परिणाम संभवतः लगभग हमेशा समान होते हैं ... जिसका अर्थ है "बेकार" प्रश्नों के बहुत सारे डेटाबेस के लिए बनाया गया है, जिसे बार-बार एक ही डेटा की सेवा करने में समय बिताना पड़ता है।
बेशक, यह अन्य सामानों के लिए सच है, जैसे वेब सेवा कॉल, अन्य वेबसाइटों से जानकारी प्राप्त करना, भारी गणना, ...

आपके लिए पहचान करना बहुत दिलचस्प हो सकता है:

• कौन से क्वेरीज़ बहुत बार चलाई जाती हैं, हमेशा एक ही डेटा को वापस करना
• कौन से अन्य (भारी) गणना बहुत समय से की जाती है, हमेशा एक ही परिणाम लौटाते हैं

और इन डेटा / परिणामों को किसी प्रकार के कैश में संग्रहीत करें, ताकि वे प्राप्त करना आसान हो - तेज - और आपको "SQL" पर "कुछ भी नहीं" के लिए जाने की आवश्यकता नहीं है।

उदाहरण के लिए महान कैशिंग तंत्र हैं:

• APC : मैंने पहले जिस ओपोड-कैश के अलावा बात की थी, वह आपको मेमोरी में डेटा स्टोर करने की अनुमति देता है,
• और / या मेमकेच्ड ( यह भी देखें ) , जो बहुत उपयोगी है यदि आपके पास शाब्दिक रूप से बहुत सारे डेटा हैं और / या एकाधिक सर्वर का उपयोग कर रहे हैं , जैसा कि यह वितरित है।
• बेशक, आप फ़ाइलों के बारे में सोच सकते हैं; और शायद कई अन्य विचार।

मुझे पूरा यकीन है कि आपका ढांचा कुछ कैश से संबंधित सामान के साथ आता है; आप शायद पहले से ही जानते हैं, जैसा कि आपने कहा था "मैं आने वाले समय में कैश-लाइब्रेरी का अधिक उपयोग करूंगा" ओपी ;-) में;

रूपरेखा

अब, एक अच्छी बात यह है कि अपने आवेदन को प्रोफाइल करने के लिए Xdebug एक्सटेंशन का उपयोग करना होगा : यह अक्सर कमजोर-स्पॉट के एक जोड़े को आसानी से खोजने की अनुमति देता है - कम से कम, अगर कोई फ़ंक्शन है जो बहुत समय लेता है।

ठीक से कॉन्फ़िगर किया गया है , यह प्रोफाइलिंग फ़ाइलों को उत्पन्न करेगा जिन्हें कुछ ग्राफिक टूल के साथ विश्लेषण किया जा सकता है, जैसे:

• KCachegrind : मेरा पसंदीदा, लेकिन केवल लिनक्स / केडीई पर काम करता है
• खिड़कियों के लिए Wincachegrind ; यह KCacheGrind की तुलना में थोड़ा कम सामान करता है, दुर्भाग्य से - यह आम तौर पर कॉलग्राफ प्रदर्शित नहीं करता है।
• Webgrind जो एक PHP वेबसर्वर पर चलता है, इसलिए कहीं भी काम करता है - लेकिन शायद इसकी विशेषताएं कम हैं।

उदाहरण के लिए, यहाँ KCacheGrind के कुछ स्क्रीनशॉट हैं:

_{(स्रोत: pascal-martin.fr ) (स्रोत: pascal-martin.fr )}

(BTW, दूसरे स्क्रीनशॉट पर प्रस्तुत कॉलगर्ल आम तौर पर न तो WinCacheGrind है और न ही Webgrind कर सकती है, अगर मुझे सही याद है ^ ^)

(टिप्पणी के लिए धन्यवाद @ मायिकुशी) एक और संभावना है कि मैंने ज्यादा इस्तेमाल नहीं किया है xhprof विस्तार: यह प्रोफाइलिंग के साथ भी मदद करता है, कॉलगर्ल उत्पन्न कर सकता है - लेकिन Xdebug की तुलना में हल्का है, जिसका मतलब है कि आपको इसे स्थापित करने में सक्षम होना चाहिए एक उत्पादन सर्वर।

आपको इसका उपयोग करने में सक्षम होना चाहिए एक्सॉनगाइड XHGui , जो डेटा के विज़ुअलाइज़ेशन में मदद करेगा।

चीजों के एसक्यूएल पक्ष पर:

अब जब हमने PHP के बारे में थोड़ा सा बोल दिया है, तो ध्यान दें कि यह अधिक से अधिक संभव है कि आपकी अड़चन चीजों के PHP-साइड नहीं है , लेकिन डेटाबेस एक ...

कम से कम दो या तीन चीजें, यहां:

• आपको यह निर्धारित करना चाहिए:
  • आपके एप्लिकेशन क्या कर रहे हैं सबसे अधिक बार पूछे जाने वाले प्रश्न हैं
  • चाहे वे ( सही अनुक्रमणिका का उपयोग कर रहे हैं , मुख्य रूप से?) , EXPLAINनिर्देश का उपयोग करते हुए , यदि आप MySQL का उपयोग कर रहे हैं
    • यह भी देखें: चयन और अन्य विवरणों का अनुकूलन
    • उदाहरण के लिए, आप उन log_slow_queriesअनुरोधों की सूची प्राप्त करने के लिए सक्रिय हो सकते हैं जो "बहुत अधिक" समय लेते हैं , और उन लोगों द्वारा अपना अनुकूलन शुरू करें।
  • क्या आप इनमें से कुछ प्रश्नों को कैश कर सकते हैं (देखें कि मैंने पहले क्या कहा था)
• क्या आपका MySQL अच्छी तरह से कॉन्फ़िगर किया गया है? मुझे इसके बारे में ज्यादा जानकारी नहीं है, लेकिन कुछ विन्यास विकल्प हैं जिनका कुछ प्रभाव हो सकता है।
  • MySQL सर्वर का अनुकूलन आपको इसके बारे में कुछ दिलचस्प जानकारी दे सकता है।

फिर भी, दो सबसे महत्वपूर्ण चीजें हैं:

• अगर आपको जरूरत न हो तो डीबी पर न जाएं: जितना हो सके उतना कैश लें !
• जब आपको DB में जाना है, तो कुशल प्रश्नों का उपयोग करें: अनुक्रमित का उपयोग करें; और प्रोफाइल!

और अब क्या?

यदि आप अभी भी पढ़ रहे हैं, तो और क्या अनुकूलित किया जा सकता है?

खैर, अभी भी सुधार की गुंजाइश है ... वास्तुकला-उन्मुख विचारों के एक जोड़े हो सकते हैं:

• एन-टियर आर्किटेक्चर पर स्विच करें:
  • MySQL को दूसरे सर्वर पर रखें (2-स्तरीय: PHP के लिए एक, MySQL के लिए दूसरा)
  • कई PHP सर्वर का उपयोग करें (और उन के बीच उपयोगकर्ताओं को लोड-संतुलन करें)
  • लाइटर वेबसर्वर के साथ, स्थिर फ़ाइलों के लिए अन्य मशीनों का उपयोग करें, जैसे:
    • lighttpd
    • या nginx - यह एक और अधिक लोकप्रिय होता जा रहा है, btw।
  • MySQL के लिए कई सर्वर, PHP के लिए कई सर्वर और उन के सामने कई रिवर्स-प्रॉक्सी का उपयोग करें
  • बेशक: जो भी सर्वर में मुफ्त रैम है, उस पर मेम्केडेड डेमॉन स्थापित करें, और उन्हें कैश करने के लिए उतना ही उपयोग करें जितना आप कर सकते हैं या समझ सकते हैं।
• कुछ "अधिक कुशल" का उपयोग करें जो अपाचे?
  • मैं नगीनेक्स के बारे में अधिक से अधिक बार सुनता हूं , जो कि PHP और उच्च-मात्रा वेबसाइटों की बात आती है, तो यह बहुत अच्छा माना जाता है; मैंने इसे स्वयं कभी इस्तेमाल नहीं किया है, लेकिन आपको इसके बारे में कुछ दिलचस्प लेख मिल सकते हैं;
    • उदाहरण के लिए, PHP प्रदर्शन III - रनिंग नगनेक्स ।
    • इसे भी देखें: PHP-FPM - FastCGI प्रोसेस मैनेजर , जिसे PHP> = 5.3.3 के साथ बंडल किया गया है, और nginx के साथ चमत्कार करता है।

ठीक है, हो सकता है कि उन विचारों में से कुछ आपकी स्थिति में थोड़ा अधिक हो। ^
लेकिन, फिर भी ... क्यों नहीं उन्हें थोड़ा अध्ययन करें, बस मामले में? ;-)

और कोहना के बारे में क्या?

अपने प्रारंभिक सवाल का उपयोग करता है Kohana ... खैर एक आवेदन के अनुकूलन के बारे में, मैं कुछ पोस्ट किया है था विचारों है कि किसी भी पीएचपी आवेदन के लिए सही हैं ... जिसका अर्थ है कि वे भी Kohana लिए सही हैं ;-)
(यह करने के लिए यहां तक कि अगर नहीं विशिष्ट ^)

मैंने कहा: कैश का उपयोग करें; कोहाना कुछ कैशिंग सामानों का समर्थन करता है (आपने इसके बारे में खुद से बात की है, इसलिए यहां कुछ भी नया नहीं है ...)
यदि ऐसा कुछ है जो जल्दी से किया जा सकता है, तो इसे आज़माएं;;;

मैंने यह भी कहा कि आपको ऐसा कुछ नहीं करना चाहिए जो आवश्यक नहीं है; क्या कोहना में डिफ़ॉल्ट रूप से कुछ ऐसा सक्षम है जिसकी आपको आवश्यकता नहीं है?
शुद्ध ब्राउज़िंग, ऐसा लगता है कि XSS फ़िल्टरिंग के बारे में कम से कम कुछ है; क्या आपको इसकी आवश्यकता है?

फिर भी, यहां कुछ लिंक दिए गए हैं जो उपयोगी हो सकते हैं:

• कोहना सामान्य चर्चा: कैशिंग?
• सामुदायिक सहायता: वेब साइट अनुकूलन: कोहाण का उपयोग करते हुए अधिकतम वेबसाइट प्रदर्शन

निष्कर्ष?

और, निष्कर्ष निकालना, एक सरल विचार:

• 5 दिनों के भुगतान के लिए आपकी कंपनी को कितना खर्च आएगा? - कुछ महान अनुकूलन करने के लिए समय की उचित मात्रा पर विचार करना
• एक दूसरे सर्वर, और उसके रखरखाव को खरीदने के लिए आपकी कंपनी को कितना भुगतान करना होगा ?
• अगर आपको बड़े पैमाने पर करना है तो क्या होगा?
  • 10 दिन बिताने में कितना खर्च आएगा? अधिक? अपने आवेदन के हर संभव बिट का अनुकूलन?
  • और कितना कुछ और सर्वर के लिए?

मैं यह नहीं कह रहा हूं कि आपको अनुकूलन नहीं करना चाहिए: आपको निश्चित रूप से चाहिए
लेकिन "त्वरित" अनुकूलन के लिए जाएं, जो आपको पहले बड़े पुरस्कार देगा : कुछ ओपकोड कैश का उपयोग करने से आपको अपने सर्वर के सीपीयू-लोड से 10 से 50 प्रतिशत के बीच मदद मिल सकती है ... और इसे स्थापित करने में केवल कुछ मिनट लगते हैं; -; ) दूसरी तरफ, 2 प्रतिशत के लिए 3 दिन खर्च ...

ओह, और, btw: कुछ भी करने से पहले: कुछ निगरानी सामान रखें , ताकि आप जान सकें कि क्या सुधार किए गए हैं, और कैसे!
मॉनिटरिंग के बिना, आपको इस बात का कोई अंदाजा नहीं होगा कि आपने क्या किया ... भले ही यह वास्तविक अनुकूलन हो या न हो!

उदाहरण के लिए, आप RRDtool + cacti जैसी किसी चीज़ का उपयोग कर सकते हैं ।
और अपने बॉस को 40% CPU-लोड ड्रॉप के साथ कुछ अच्छे ग्राफिक्स दिखाना हमेशा महान होता है ;-)

वैसे भी, और वास्तव में निष्कर्ष निकालना: मज़े करो!
(हाँ, अनुकूलन मज़ेदार है!)
(अर्घ, मैंने नहीं सोचा था कि मैं इतना लिखूंगा ... आशा है कि इसके कम से कम कुछ हिस्से उपयोगी हैं ... और मुझे यह उत्तर याद रखना चाहिए: कुछ अन्य समय में उपयोगी हो सकता है। ..)

Comments

5 दिनों के लिए डेवलपर काम करने की तुलना में नए सर्वर को जोड़ना सस्ता हो सकता है, यह मत भूलो कि कई सर्वरों से चलने पर आपका सॉफ़्टवेयर ठीक से काम नहीं कर सकता है (आपको किसी भी तरह सर्वर पर फ़ाइलों को साझा करना पड़ सकता है - एनएफएस दर्द हो सकता है, आप सत्र का उपयोग कर रहे हैं; बेहतर उन्हें DB, आदि) में स्थानांतरित करें। और वह अपने आप में डेवलपर को चीजों पर काम करने की आवश्यकता होगी।

— NSSec

महान व्याख्या! क्या आपके पास एक ब्लॉग है जिसकी मैं सदस्यता ले सकता हूं? :-)

— ग्रे पैंथर

@ dnh828: मैंने इसे कुछ अन्य अवसरों के लिए फिर से उपयोग करने की उम्मीद में लिखा था (मैं वास्तव में पहले से ही था;); @ मैथ्यू: निश्चित रूप से सच (सत्रों के बारे में, हालांकि, डीबी के बजाय, आप मेमेचेचे का उपयोग करके परिकल्पना कर सकते हैं) ;; @ सीडी- MaN: धन्यवाद! मेरे पास वास्तव में एक ब्लॉग है, लेकिन यह फ्रेंच में है और मैं वास्तव में अक्सर ब्लॉग नहीं करता हूँ ... फिर भी, यदि आप रुचि रखते हैं: blog.pascal-martin.fr

— पास्कल मार्टिन

XHProf ( pecl.php.net/package/xhprof ) पर एक नज़र डालने पर विचार करें , मुझे अपने कोड को प्रोफ़ाइल करने के लिए XDebug से बेहतर लगता है, विशेष रूप से उत्पादन सर्वर पर, XHGui ( github.com/finheimer/xhprof ) के साथ मिलकर यह एक वास्तविक आनंद है काम साथ में करने केलिए।

— मिकुशी

बहुत बुरा है, है ना? ;-); हालाँकि आप कुछ कर सकते हैं, इस सवाल को साझा करने के लिए stackoverflow.com/q/1260134/138475 लिंक का उपयोग करना है - इसलिए अधिक लोग इस उत्तर को पढ़ सकते हैं (ठीक यही कारण है कि मैंने ऐसा लंबा उत्तर लिखा है: इसके लिए be ^ ^) पढ़ें

— पास्कल मार्टिन

Answer 2

प्रोफ़ाइल कोड धीमा करने और उसका विश्लेषण करने के लिए XDebug और WinCacheGrind या WebCacheGrind का उपयोग करें ।

_{(स्रोत: jokke.dk )}

Answer 3

XDebug के साथ प्रोफाइल कोड ।

बहुत सारे कैशिंग का उपयोग करें। यदि आपके पृष्ठ अपेक्षाकृत स्थिर हैं, तो रिवर्स प्रॉक्सी इसे करने का सबसे अच्छा तरीका हो सकता है।

Answer 4

डेटाबेस ऑब्जेक्ट्स के उपयोग को छोड़कर कोहना बहुत तेजी से बॉक्स से बाहर है। Zombor को उद्धृत करने के लिए "आप परिणाम सरणियों के बजाय डेटाबेस परिणाम ऑब्जेक्ट का उपयोग करके यह सुनिश्चित करके मेमोरी उपयोग को कम कर सकते हैं।" यह एक साइट पर एक बड़ा प्रदर्शन अंतर बनाता है जिसे पटक दिया जा रहा है। न केवल यह अधिक मेमोरी का उपयोग करता है, यह स्क्रिप्ट के निष्पादन को धीमा कर देता है।

इसके अलावा - आपको कैशिंग का उपयोग करना चाहिए। मैं मेमेचे को पसंद करता हूं और इसे अपने मॉडल में इस तरह से उपयोग करता हूं:

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

यह भी नाटकीय रूप से प्रदर्शन में वृद्धि करेगा। उपरोक्त दो तकनीकों ने साइटों के प्रदर्शन में 80% तक सुधार किया।

यदि आपको लगता है कि आपको अड़चन कहां है, इस बारे में कुछ और जानकारी दी गई है, तो मुझे यकीन है कि हम कुछ बेहतर विचार दे सकते हैं।

इसके अलावा कुछ अन्य प्रदर्शन युक्तियों के लिए yslow (इसे गूगल करें) देखें।

Answer 5

कोहाना से संबंधित सख्ती (आप शायद पहले से ही ऐसा कर चुके हैं, या नहीं):

उत्पादन मोड में:

1. आंतरिक कैशिंग सक्षम करें (यह केवल कोहना :: find_file परिणामों को कैश करेगा, लेकिन यह वास्तव में बहुत मदद कर सकता है।
2. प्रोफाइलर को अक्षम करें

बस मेरे 2 सेंट :)

Answer 6

मैं XDebug और कैशिंग जवाबों से पूरी तरह सहमत हूं। अनुकूलन के लिए कोहना परत को तब तक न देखें जब तक आप अपनी सबसे बड़ी गति और पैमाने की अड़चनों की पहचान नहीं कर लेते।

XDebug आपको बताएगा कि आप अपना अधिकांश समय व्यतीत कर रहे थे और अपने कोड में 'हॉटस्पॉट' की पहचान कर रहे थे। इस रूपरेखा जानकारी को रखें ताकि आप प्रदर्शन सुधारों को आधार बना सकें और माप सकें।

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