एक उच्च-लोड साइट में PHP का उपयोग करने के लिए रणनीति

Question

इससे पहले कि आप इसका उत्तर दें मैंने कभी भी उच्च सर्वर भार प्राप्त करने के लिए पर्याप्त लोकप्रिय कुछ भी विकसित नहीं किया है। मेरे साथ ऐसा व्यवहार करो (विलाप) जो एक ग्रह पर उतरा हो, जो पीएचपी और कुछ अनुकूलन तकनीकों को जानता हो।

---

मैं PHP में एक उपकरण विकसित कर रहा हूं जो कि बहुत सारे उपयोगकर्ताओं को प्राप्त कर सकता है, अगर यह सही काम करता है। हालाँकि, जब मैं इस कार्यक्रम को विकसित करने में पूरी तरह से सक्षम हूँ, तो मैं बहुत अव्यवस्थित हूँ जब यह कुछ ऐसा बनाने की बात आती है जो विशाल यातायात से निपट सकता है। तो यहाँ इस पर कुछ प्रश्न हैं (इस प्रश्न को संसाधन थ्रेड में बदलने के लिए स्वतंत्र महसूस करें)।

डेटाबेस

फिलहाल मैं PHP5 में MySQLi सुविधाओं का उपयोग करने की योजना बना रहा हूं। हालांकि मुझे उपयोगकर्ताओं और सामग्री के संबंध में डेटाबेस को कैसे सेटअप करना चाहिए? क्या मुझे वास्तव में कई डेटाबेस की आवश्यकता है? फिलहाल सब कुछ एक डेटाबेस में उछाला गया है - हालांकि मैं एक के लिए उपयोगकर्ता डेटा फैलाने, दूसरे के लिए वास्तविक सामग्री और अंत में कोर साइट सामग्री (टेम्पलेट स्वामी आदि) पर विचार कर रहा हूं। इसके पीछे मेरा तर्क यह है कि विभिन्न डेटाबेस में प्रश्न भेजने से उन पर एक डेटाबेस = 3 लोड स्रोतों के रूप में लोड कम हो जाएगा। यदि यह सब एक ही सर्वर पर होते तो भी यह प्रभावी होता?

कैशिंग

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

इस पर मेरा सवाल:

कहें कि मेरे पास विभिन्न लेखों पर टिप्पणियाँ हैं। जो एक बेहतर समाधान है: सरल टिप्पणी टेम्पलेट को स्टोर करें और टिप्पणियों (डीबी कॉल से) को हर बार पृष्ठ लोड होने या HTML पृष्ठ के रूप में टिप्पणी पृष्ठ की एक कैश्ड कॉपी स्टोर करें - हर बार एक टिप्पणी जोड़ी जाती है / संपादित / हटा दी जाती है पृष्ठ पुन: संलग्न है।

आखिरकार

क्या किसी के पास PHP पर एक उच्च लोड साइट चलाने के लिए कोई सुझाव / संकेत हैं। मुझे पूरा यकीन है कि यह उपयोग करने के लिए एक व्यावहारिक भाषा है - फेसबुक और याहू! इसे बहुत पूर्वता दें - लेकिन क्या मुझे कोई अनुभव होना चाहिए?

Comments

3.5 साल बाद और मुझे यह भी याद नहीं है कि मैं क्या काम कर रहा था, मैं जानना चाहता हूं कि मुझे क्या लगा कि यह बहुत अच्छा था :)

— Ross

यह आपको समय से पहले अनुकूलन के बारे में एक सबक होने दें :)

— रिमु एटकिंसन

Answer 1

कोई भी दो साइट एक जैसे नहीं हैं। आपको वास्तव में jmeter और बेंचमार्क जैसे टूल प्राप्त करने की आवश्यकता है, यह देखने के लिए कि आपकी समस्या कहाँ होगी। आप अनुमान लगाने और सुधारने में बहुत समय बिता सकते हैं, लेकिन जब तक आप माप नहीं लेते और अपने परिवर्तनों की तुलना नहीं करते तब तक आपको वास्तविक परिणाम नहीं दिखेंगे।

उदाहरण के लिए, कई वर्षों के लिए, MySQL क्वेरी कैश हमारी सभी प्रदर्शन समस्याओं का समाधान था। यदि आपकी साइट धीमी थी, तो MySQL विशेषज्ञों ने क्वेरी कैश चालू करने का सुझाव दिया। यह पता चला है कि यदि आपके पास उच्च भार है, तो कैश वास्तव में अपंग है। यदि आपने इसे बिना परीक्षण के चालू कर दिया, तो आप कभी नहीं जान पाएंगे।

और यह मत भूलो कि तुम कभी स्केलिंग नहीं करते हो। 10req / s को हैंडल करने वाली साइट को 1000req / s का समर्थन करने के लिए परिवर्तनों की आवश्यकता होगी। और अगर आप 10,000req / s का समर्थन करने के लिए पर्याप्त भाग्यशाली हैं, तो आपकी वास्तुकला संभवतः पूरी तरह से अलग दिखेगी।

डेटाबेस

• MySQLi का उपयोग न करें - PDO 'आधुनिक' OO डेटाबेस एक्सेस लेयर है। उपयोग करने के लिए सबसे महत्वपूर्ण विशेषता आपके प्रश्नों में प्लेसहोल्डर है। यह सर्वर साइड तैयार करने और आपके लिए अन्य अनुकूलन का उपयोग करने के लिए पर्याप्त स्मार्ट है।
• आप शायद इस बिंदु पर अपने डेटाबेस को तोड़ना नहीं चाहते हैं। यदि आप पाते हैं कि एक डेटाबेस नहीं कट रहा है, तो आपके ऐप के आधार पर स्केल करने के लिए कई तकनीकें हैं। अतिरिक्त सर्वरों की प्रतिकृति आमतौर पर अच्छी तरह से काम करती है यदि आपके पास लिखने की तुलना में अधिक है। शेयरिंग कई मशीनों पर अपने डेटा को विभाजित करने की एक तकनीक है।

कैशिंग

• आप शायद अपने डेटाबेस में कैश नहीं करना चाहते हैं। डेटाबेस आमतौर पर आपकी अड़चन है, इसलिए इसमें अधिक IO जोड़ना आमतौर पर एक बुरी बात है। वहाँ कई PHP कैश वहाँ हैं जो APC और Zend जैसी चीजों को पूरा करते हैं ।
• कैशिंग के साथ अपने सिस्टम को मापें। मैं शर्त लगाता हूं कि आपके कैश सीधे पृष्ठों की सेवा की तुलना में भारी है।
• यदि db से अपनी टिप्पणियों और लेख डेटा को बनाने में लंबा समय लगता है, तो अपने सिस्टम में मेमकाच को एकीकृत करें। आप क्वेरी परिणामों को कैश कर सकते हैं और उन्हें एक उदाहरण में संग्रहीत कर सकते हैं। यह याद रखना महत्वपूर्ण है कि किसी भी लाभ को देखने के लिए डेटाबेस से डेटा को पुनः प्राप्त करना डेटाबेस से इसे इकट्ठा करने से तेज होना चाहिए।
• यदि आपके लेख गतिशील नहीं हैं, या आपके उत्पन्न होने के बाद आपके पास साधारण गतिशील परिवर्तन हैं, तो डिस्क पर html या php लिखने पर विचार करें। आपके पास एक index.php पृष्ठ हो सकता है जो लेख के लिए डिस्क पर दिखता है, अगर यह वहां है, तो यह क्लाइंट को स्ट्रीम करता है। यदि ऐसा नहीं है, तो यह लेख उत्पन्न करता है, इसे डिस्क पर लिखता है और क्लाइंट को भेजता है। डिस्क से फ़ाइलों को हटाने से पृष्ठों को फिर से लिखा जाएगा। यदि कोई टिप्पणी किसी लेख में जोड़ी जाती है, तो कैश्ड प्रतिलिपि को हटा दें - इसे पुनर्जीवित किया जाएगा।

Comments

@ राइटिंग टू डिस्क। आप index.php को भी खोद सकते हैं और Apache को आपके लिए काम करने देता है, ताकि index.php को ही कहा जाता है, यदि पथ मौजूद नहीं है। आप इसके लिए mode_rewrite का उपयोग करेंगे।

— troelskn

-1, PDO MySQLi या यहाँ तक कि MySQL एक्सटेंशन की तुलना में काफी धीमा है।

— एलिक्स एक्सल

PDO, mysqli की तुलना में बहुत धीमा था और मेरे लिए नेस्टेड प्रश्नों के लिए सही काम नहीं करता था। मैसकली भी पीडीओ की तरह ही सर्वर साइड की तैयारियों और बाध्य मापदंडों का समर्थन करता है।

— डैरन श्वेनेके

मैं विश्वास नहीं कर सकता कि यह एक जवाब के रूप में स्वीकार किया गया था। यह बहुत अच्छा नहीं है।

— सिम्बियन

के बारे में: कैशिंग - चित्र, सीएसएस, एचटीएम और जेएस मदद करेंगे, छवियों पर कुकीज़ भी बंद करें!

— तलवी वटिया

Answer 2

मैं 15M से अधिक उपयोगकर्ताओं के साथ एक साइट पर लीड डेवलपर हूं। हमें बहुत कम स्केलिंग की समस्या हुई है क्योंकि हमने इसके लिए योजना बनाई है और बहुत सोच-समझकर बढ़ाया है। यहाँ कुछ रणनीतियाँ हैं जो मैं अपने अनुभव से सुझा सकता हूँ।

SCHEMA सबसे पहले, अपने स्कीमा को असामान्य करें। इसका मतलब यह है कि कई संबंधपरक तालिकाओं के बजाय, आपको एक बड़ी तालिका रखने का विकल्प चुनना चाहिए। सामान्य तौर पर, जॉइन कीमती डीबी संसाधनों की बर्बादी होती है क्योंकि कई तैयारियां और टकराव डिस्क I / O की जलता है। जब आप कर सकते हैं तो उनसे बचें।

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

INDEXING सुनिश्चित करें कि आपके प्रश्न कम से कम एक अनुक्रमणिका का उपयोग करें। हालाँकि, यदि आप लिखते हैं या बार-बार अपडेट करते हैं, तो उस अनुक्रमणिका पर आपका खर्च आएगा। इससे बचने के लिए कुछ प्रायोगिक टोटके हैं।

आप उन अतिरिक्त स्तंभों को जोड़ने का प्रयास कर सकते हैं जो अनुक्रमित नहीं हैं जो आपके स्तंभों के समानांतर चलते हैं जो अनुक्रमित हैं। फिर आपके पास एक ऑफ़लाइन प्रक्रिया हो सकती है जो बैचों में अनुक्रमित स्तंभों पर गैर-अनुक्रमित कॉलम लिखती है। इस तरह, आप बेहतर तरीके से नियंत्रित कर सकते हैं जब mySQL को इंडेक्स को पुनः प्राप्त करने की आवश्यकता होगी।

एक प्लेग की तरह संगणित प्रश्नों से बचें। यदि आपको किसी क्वेरी की गणना करनी है, तो इसे लिखने के समय एक बार करने का प्रयास करें।

कैशिंग मैं अत्यधिक memcached सलाह देते हैं। यह PHP स्टैक (फेसबुक) पर सबसे बड़े खिलाड़ियों द्वारा सिद्ध किया गया है और बहुत लचीला है। ऐसा करने के दो तरीके हैं, एक आपके डीबी परत में कैशिंग कर रहा है, दूसरा आपके व्यवसाय तर्क परत में कैशिंग कर रहा है।

DB परत विकल्प को DB से प्राप्त प्रश्नों के परिणाम को कैशिंग करने की आवश्यकता होगी। आप अपनी SQL क्वेरी को md5 () का उपयोग करके और डेटाबेस में जाने से पहले लुकअप कुंजी के रूप में उपयोग कर सकते हैं। इसका उल्टा यह है कि इसे लागू करना बहुत आसान है। नकारात्मक पक्ष (कार्यान्वयन पर निर्भर करता है) यह है कि आप लचीलापन खो देते हैं क्योंकि आप कैश समाप्ति के संबंध में सभी कैशिंग के साथ एक ही व्यवहार कर रहे हैं।

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

डेटा चेतावनी प्रतिकृति केवल आपको अब तक मिलती है। जितनी जल्दी आप उम्मीद करते हैं, उतना ही आपका लेखन एक अड़चन बन जाएगा। क्षतिपूर्ति करने के लिए, जल्द से जल्द डेटा शार्किंग का समर्थन करना सुनिश्चित करें। यदि आप नहीं करते हैं तो आप संभवतः अपने आप को बाद में शूट करना चाहेंगे।

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

इसका नकारात्मक पक्ष यह है कि एक से अधिक शार्क के डेटा को एक साथ रखना मुश्किल हो सकता है। लेकिन, आप उस तरह से भी अपने तरीके से इंजीनियर कर सकते हैं।

ऑफ़लाइन प्रक्रिया उपयोगकर्ता को आपके बैकएंड की प्रतीक्षा न करें यदि उनके पास नहीं है। एक नौकरी कतार बनाएँ और किसी भी प्रसंस्करण को स्थानांतरित करें जिसे आप ऑफ़लाइन कर सकते हैं, इसे उपयोगकर्ता के अनुरोध से अलग कर सकते हैं।

Comments

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

— इवान प्लाइस

डेटा शार्पिंग उन डेटाबेस के लिए आवश्यक है जो बहुत बड़े हो जाते हैं। Google (सर्च इंजन नहीं कंपनी) के पास बहुत सारी दिलचस्प बातें हैं जो कि योजनाओं को लागू करने के बारे में बताती हैं। ऑफ़लाइन प्रसंस्करण भी बहुत बड़ा है जब यह डेटाबेस की संख्या को सीमित करने के लिए नीचे आता है (और तालिका सूचकांक पुनर्गणना की संख्या को सीमित करता है)। मैंने बहुत सारे ब्लॉग देखे हैं (और मुझे लगता है कि स्टैक ओवरफ़्लो भी) इस तकनीक का उपयोग अपने उपयोगकर्ता-जनित टिप्पणी / प्रतिक्रिया प्रणालियों के लिए करता है।

— इवान प्लाइस

टिप्पणियों के लिए धन्यवाद। यह आश्चर्यजनक है कि मध्य-स्तरीय कोड की रूपरेखा के लिए कुछ तर्क देते हैं जब निष्पादन समय की सबसे बड़ी राशि I / O या क्लाइंट-सर्वर I / O दोनों में खर्च की जाती है। एक PHP प्रक्रिया के 40% के निष्पादन-समय से 20% की बचत करने वाला एक ऑबर कॉम्प्लेक्स ऑप्टिमाइज़ेशन, 1s डेटाबेस क्वेरी के सरल 5% बचत की तुलना में 40ms लेता है।

— thesmart

Answer 3

मैंने कुछ साइटों पर काम किया है, जिन्हें PHP & MySQL द्वारा लाखों / हिट / महीने मिलते हैं। यहाँ कुछ मूल बातें हैं:

1. कैश, कैश, कैश। कैशिंग आपके वेबसर्वर और डेटाबेस पर लोड को कम करने के सबसे सरल और प्रभावी तरीकों में से एक है। कैश पेज की सामग्री, प्रश्न, महंगी गणना, कुछ भी जो I / O बाध्य है। मेमेचेस मृत सरल और प्रभावी है।
2. एक बार जब आप अधिकतम हो जाते हैं तो कई सर्वरों का उपयोग करें। आपके पास कई वेब सर्वर और कई डेटाबेस सर्वर (प्रतिकृति के साथ) हो सकते हैं।
3. अपने webservers के अनुरोध के समग्र # को कम करें। यह जेएस, सीएसएस और छवियों को समाप्त करने वाले हेडर का उपयोग करके कैशिंग करता है। आप अपनी स्थैतिक सामग्री को एक CDN पर भी स्थानांतरित कर सकते हैं, जो आपके उपयोगकर्ता के अनुभव को गति देगा।
4. माप और बेंचमार्क। अपने उत्पादन मशीनों पर Nagios चलाएँ और अपने देव / qa सर्वर पर परीक्षण लोड करें। आपको यह जानना होगा कि आपका सर्वर कब आग पकड़ लेगा ताकि आप उसे रोक सकें।

मैं बिल्डिंग स्केलेबल वेबसाइटों को पढ़ने की सलाह दूंगा , यह फ्लिकर इंजीनियरों में से एक द्वारा लिखा गया था और यह एक महान संदर्भ है।

स्केलेबिलिटी के बारे में मेरे ब्लॉग पोस्ट को भी देखें, इसमें कई भाषाओं और प्लेटफार्मों के साथ स्केलिंग के बारे में प्रस्तुतियों के बहुत सारे लिंक हैं: http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

Comments

+1 यहाँ बहुत सारी अच्छी जानकारी है। मैं हाल ही में इस विषय पर अधिक शोध कर रहा हूं और आपका उत्तर मेरे द्वारा पढ़ी गई सभी बातों के अनुरूप है। स्थैतिक सामग्री के लिए मेकचे, कैशिंग, सीडीएन, अनुरोधों को कम करना; सभी अच्छे सामान। मैं स्थैतिक सामग्री फ़ाइलों (यदि आपका CDN / कैश के पीछे है) सर्वर-साइड पर भी हैश उत्पन्न करता, तो अपडेट की गई फ़ाइलों में कैश में एक अद्वितीय हस्ताक्षर होता है। साथ ही, अनुरोध पर स्थैतिक स्रोत फ़ाइलों (css, javascript) को फ्लाई (और उन्हें फ़ाइल नाम हैश के साथ कैश) में जोड़ दें। इसके अलावा, अंगूठे को गतिशील रूप से उत्पन्न करें (और उन्हें कैश में स्टोर करें)

— इवान प्लाइस

Google ने mod_pagespeed नामक एक अपाचे मॉड्यूल बनाया है जो सभी स्थैतिक सामग्री के लिए फ़ाइल समाकलन, लघुकरण, फ़ाइल का नाम बदलने के लिए हैश इत्यादि को संभाल सकता है। यह केवल तब तक सर्वरों में थोड़ा सा प्रोसेसिंग ओवरहेड जोड़ देगा जब तक कि कैश (और CDN (s)) अधिकांश सामग्री के साथ पॉप्युलेट नहीं हो जाते हैं। इसके अलावा, सुरक्षा के लिए, यह आम तौर पर एक ही डेटाबेस में सार्वजनिक रूप से सुलभ (उपयोगकर्ता) टेबल रखने के लिए एक बुरा विचार है क्योंकि बैक-एंड (यदि किसी कारणवश टेबल में से किसी को हैक किया जाना था) की तुलना में टेबल के रूप में।

— इवान प्लाइस

Answer 4

पुन: PDO / MySQLi / MySQLND

@ गैरी

आप बस यह नहीं कह सकते कि "MySQLi का उपयोग न करें" क्योंकि उनके अलग-अलग लक्ष्य हैं। पीडीओ लगभग एक अमूर्त परत की तरह है (हालांकि यह वास्तव में नहीं है) और इसे कई डेटाबेस उत्पादों का उपयोग करने के लिए आसान बनाने के लिए डिज़ाइन किया गया है जबकि MySQLi MySQL सम्मेलनों के लिए विशिष्ट है। यह कहना गलत है कि PDO, MySQLi से तुलना करने के संदर्भ में आधुनिक एक्सेस लेयर है क्योंकि आपके कथन का तात्पर्य है कि प्रगति mysql -> mysqli -> PDO की रही है जो मामला नहीं है।

MySQLi और PDO के बीच चयन सरल है - यदि आपको कई डेटाबेस उत्पादों का समर्थन करने की आवश्यकता है तो आप PDO का उपयोग करते हैं। यदि आप MySQL का उपयोग कर रहे हैं तो आप PDO और MySQLi के बीच चयन कर सकते हैं।

तो आप PDO पर MySQLi को क्यों चुनेंगे? निचे देखो...

@ross

आप MySQLnd के बारे में सही हैं जो नवीनतम MySQL Core भाषा स्तर की लाइब्रेरी है, हालाँकि यह MySQLi का प्रतिस्थापन नहीं है। MySQLi (PDO के साथ) आपके PHP कोड के माध्यम से MySQL के साथ बातचीत करने का तरीका बना हुआ है। ये दोनों PHP कोड के पीछे C क्लाइंट के रूप में libmysql का उपयोग करते हैं। समस्या यह है कि libmysql कोर PHP इंजन के बाहर है और यहीं पर mysqlnd आता है। यह एक मूल चालक है, जो दक्षता बढ़ाने के लिए विशेष रूप से जहाँ मेमोरी के उपयोग का संबंध रखता है, मुख्य PHP आंतरिक का उपयोग करता है।

MySQLnd को MySQL द्वारा स्वयं विकसित किया जा रहा है और हाल ही में PHP 5.3 शाखा पर उतरा है जो RC परीक्षण में है, जो इस वर्ष के अंत में रिलीज़ के लिए तैयार है। तब आप MySQLi के साथ MySQLnd का उपयोग कर सकेंगे ... लेकिन PDO के साथ नहीं। यह MySQLi को कई क्षेत्रों (सभी नहीं) में एक प्रदर्शन को बढ़ावा देगा और यदि आप पीडीओ की क्षमताओं जैसी अमूर्तता की आवश्यकता नहीं है, तो यह MySQL बातचीत के लिए सबसे अच्छा विकल्प बना देगा।

उस ने कहा, MySQLnd अब पीडीओ के लिए PHP 5.3 में उपलब्ध है और इसलिए आप ND से पीडीओ में प्रदर्शन संवर्द्धन का लाभ प्राप्त कर सकते हैं, हालाँकि, पीडीओ अभी भी एक जेनेरिक डेटाबेस परत है और इसलिए इससे अधिक लाभ होने की संभावना नहीं है एनडी में वृद्धि MySQLi के रूप में कर सकते हैं ।

कुछ उपयोगी बेंचमार्क यहां मिल सकते हैं, हालांकि वे 2006 से हैं। आपको इस विकल्प जैसी चीजों के बारे में भी जानकारी होनी चाहिए ।

MySQLi और PDO के बीच निर्णय लेते समय कई बातों पर ध्यान दिया जाना चाहिए। वास्तविकता यह है कि यह तब तक मायने नहीं रखता है जब तक आप उच्च अनुरोध संख्याओं को प्राप्त नहीं करते हैं और उस मामले में, यह एक एक्सटेंशन का उपयोग करने के लिए अधिक समझ में आता है जो विशेष रूप से MySQL के लिए डिज़ाइन किया गया है जो एक चीज़ों को सार करता है और एक MySQL ड्राइवर प्रदान करने के लिए होता है। ।

यह एक सरल मामला नहीं है, जो सबसे अच्छा है क्योंकि प्रत्येक के फायदे और नुकसान हैं। आपको मेरे द्वारा प्रदान किए गए लिंक को पढ़ने और अपने स्वयं के निर्णय के साथ आने की आवश्यकता है, फिर इसका परीक्षण करें और पता करें। मैंने पिछले प्रोजेक्ट्स में PDO का उपयोग किया है और यह एक अच्छा विस्तार है लेकिन शुद्ध प्रदर्शन के लिए मेरी पसंद MySQLND होगा नया MySQLND विकल्प संकलित (जब PHP 5.3 जारी किया गया है)।

Comments

मैंने पीडीओ से माइस्क्ली पर स्विच किया और नियमित प्रश्नों ने 2 गुना तेजी से निष्पादित करना शुरू कर दिया।

— नाग

@serg: इस बात की पुष्टि करने के लिए कुछ परीक्षण पोस्ट करने की परवाह है ?, क्योंकि मुझे गंभीरता से संदेह है कि बस पीडीओ से mysqli पर स्विच करने से आपको इतनी गति मिलेगी।

— स्टेन

Answer 5

सामान्य

• वास्तविक दुनिया लोड देखने के लिए प्रारंभ करने से पहले अनुकूलित करने का प्रयास न करें। आप सही अनुमान लगा सकते हैं, लेकिन यदि आप नहीं करते हैं, तो आपने अपना समय बर्बाद किया है।
• साइट को बेंचमार्क करने के लिए jmeter , xdebug या किसी अन्य टूल का उपयोग करें ।
• यदि लोड एक समस्या है, तो ऑब्जेक्ट या डेटा कैशिंग की संभावना होगी, इसलिए आमतौर पर कैशिंग विकल्पों (मेमस्कैड, MySQL कैशिंग विकल्पों) पर पढ़ा जाता है।

कोड

• अपना कोड प्रोफाइल करें ताकि आपको पता चले कि अड़चन कहां है, और यह कोड या डेटाबेस में है या नहीं

डेटाबेस

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

कैशिंग

• कैशिंग कोड, ऑब्जेक्ट्स और डेटा पर बहुत लेखन किया गया है। APC , Zend Optimizer , memcached , QuickCache , JPCache पर लेख देखें । इससे पहले कि आप वास्तव में की जरूरत है, और आप इसे बंद करने के बारे में कम चिंतित होंगे।
• APC और Zend ऑप्टिमाइज़र opcode caches हैं, वे reparsing और कोड के recompilation से बचने के द्वारा PHP कोड को गति देते हैं। आम तौर पर स्थापित करने के लिए सरल, जल्दी करने लायक।
• मेमकाटेड एक सामान्य कैश है, जिसका उपयोग आप क्वेरी, PHP फ़ंक्शंस या ऑब्जेक्ट या संपूर्ण पृष्ठों को कैश करने के लिए कर सकते हैं। कोड का उपयोग करने के लिए विशेष रूप से लिखा जाना चाहिए, जो एक संलिप्त प्रक्रिया हो सकती है यदि कैश्ड वस्तुओं के निर्माण, अद्यतन और विलोपन को संभालने के लिए कोई केंद्रीय बिंदु नहीं हैं।
• QuickCache और JPCache फ़ाइल कैश हैं, अन्यथा मेम्केड के समान। मूल अवधारणा सरल है, लेकिन इसके लिए भी कोड की आवश्यकता है और निर्माण, अद्यतन और विलोपन के केंद्रीय बिंदुओं के साथ आसान है।

विविध

• उच्च भार के लिए वैकल्पिक वेब सर्वर पर विचार करें। जैसे सर्वर lighthttp और nginx से बहुत कम स्मृति में यातायात की बड़ी मात्रा में संभाल कर सकते हैं अपाचे , यदि आप अपाचे की शक्ति और लचीलापन का त्याग कर सकते हैं (या तुम सिर्फ उन चीजों, अक्सर, तुम नहीं जो की जरूरत नहीं है)।
• याद रखें कि हार्डवेयर इन दिनों आश्चर्यजनक रूप से सस्ता है, इसलिए कोड के एक बड़े ब्लॉक को अनुकूलित करने के प्रयास में खर्च करना सुनिश्चित करें "चलो एक राक्षस सर्वर खरीदें।"
• इस सवाल पर "MySQL" और "स्केलिंग" टैग जोड़ने पर विचार करें

Answer 6

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

मैं आपके कार्यक्रम में अड़चनों को खोजने के लिए Xdebug चलाने की अत्यधिक सलाह देता हूं । इसने मेरे लिए अनुकूलन को एक हवा बना दिया।

Answer 7

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

अपने डेटाबेस प्रश्नों की रूपरेखा तैयार करने का प्रयास करें, यह पता लगाएं कि क्या धीमा है और क्या होता है और उसी से अनुकूलन रणनीति के साथ आते हैं।

मैं Memcached की जाँच करूँगा क्योंकि यह उच्च लोड साइटों का सभी प्रकार की कुशलता से कैशिंग सामग्री के लिए उपयोग होता है, और इसके लिए PHP ऑब्जेक्ट इंटरफ़ेस काफी अच्छा है।

सर्वर के बीच डेटाबेस को विभाजित करना और किसी प्रकार की लोड बैलेंसिंग तकनीक का उपयोग करना (जैसे आवश्यक डेटा के साथ 1 और # निरर्थक डेटाबेस के बीच एक यादृच्छिक संख्या उत्पन्न करना - और उस नंबर का उपयोग करके यह निर्धारित करना कि कौन सा डेटाबेस सर्वर से कनेक्ट करना है) भी बढ़ाने का एक शानदार तरीका हो सकता है। दक्षता।

ये सभी अतीत में कुछ अच्छी तरह से उच्च लोड साइटों के लिए बहुत अच्छी तरह से काम कर चुके हैं। आशा है कि यह आपको आरंभ करने में मदद करता है :-)

Comments

RequiredFullQuote: "हमें छोटी क्षमताओं के बारे में भूलना चाहिए, 97% समय के बारे में कहना चाहिए: समय से पहले अनुकूलन सभी बुराई की जड़ है"

— एलिस्टर बुलमैन

RequiredReallyFullQuote: "प्रोग्रामर अपने कार्यक्रमों के गैर-महत्वपूर्ण भागों की गति के बारे में सोचने, या चिंता करने में बहुत समय बर्बाद करते हैं, और दक्षता पर इन प्रयासों का वास्तव में एक मजबूत नकारात्मक प्रभाव पड़ता है जब डिबगिंग और रखरखाव पर विचार किया जाता है। हमें छोटी क्षमता के बारे में भूलना चाहिए।" 97% समय के बारे में कहें: समय से पहले अनुकूलन सभी बुराई की जड़ है। फिर भी हमें उस महत्वपूर्ण% में अपने अवसरों को पारित नहीं करना चाहिए। "

— cHao

Answer 8

Xdebug की तरह कुछ के साथ अपने ऐप को प्रोफाइल करना (जैसे tj9991 अनुशंसित) निश्चित रूप से एक होना चाहिए। यह पूरी तरह से आँख बंद करके चीजों को अनुकूलित करने के लिए जाने का एक बहुत मतलब नहीं है। Xdebug आपको अपने कोड में वास्तविक अड़चनों को खोजने में मदद करेगा ताकि आप अपना अनुकूलन समय समझदारी से बिता सकें और कोड के उन हिस्सों को ठीक कर सकें जो वास्तव में धीमी गति के कारण होते हैं।

यदि आप अपाचे का उपयोग कर रहे हैं, तो एक और उपयोगिता जो परीक्षण में मदद कर सकती है वह है घेराबंदी । यह आपको यह अनुमान लगाने में मदद करेगा कि आपका सर्वर और एप्लिकेशन वास्तव में अपने पेस के माध्यम से उच्च भार पर कैसे प्रतिक्रिया करेगा।

PHP के लिए किसी भी तरह का ओपकोड कैश (एपीसी या कई अन्य में से एक) भी बहुत मदद करेगा।

Answer 9

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

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

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

अब आपको बस यह तय करना है कि क्या कोई क्वेरी कैश्ड (और संभवतः आउट ऑफ डेट) परिणाम का उपयोग कर सकती है या नहीं। उपयोगकर्ताओं द्वारा चलाए जा रहे अधिकांश प्रश्नों को अब सीधे मेम्चेचे से लिया जाता है। अपवाद अद्यतन और आवेषण हैं, जो मुख्य वेबसाइट के लिए केवल लॉगिंग के कारण होता है। इसके बजाय सरल उपाय ने हमारे सर्वर लोड को लगभग 80% कम कर दिया।

Answer 10

इसके लायक क्या है, कैशिंग PHP में एक्सटेंशन / हेल्पर पैकेज के बिना भी मेमरी की तरह DIRT SIMPLE है।

आपको केवल एक आउटपुट बफ़र का उपयोग करना है ob_start()।

एक वैश्विक कैश फ़ंक्शन बनाएँ। कॉल करें ob_start, फ़ंक्शन को कॉलबैक के रूप में पास करें। फ़ंक्शन में, पृष्ठ के कैश्ड संस्करण को देखें। यदि मौजूद है, तो सेवा करें और अंत करें।

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

कुछ समाप्ति / कचरा संग्रह में जोड़ें।

और बहुत से लोग महसूस नहीं करते कि आप घोंसला बना सकते हैं ob_start()/ ob_end()कॉल कर सकते हैं। इसलिए यदि आप पहले से ही आउटपुट बफर का उपयोग कर रहे हैं, कहते हैं, विज्ञापनों में पार्स करें या सिंटैक्स हाइलाइटिंग करें या जो भी हो, आप किसी अन्य ob_start/ob_endकॉल को घोंसला दे सकते हैं।

Comments

+1 क्योंकि यह एक दिलचस्प विचार है। मुझे नहीं पता कि यह प्रदर्शन-वार कितना अच्छा काम करता है

— सिल्वरड्रेग

+1 क्योंकि यह एक दिलचस्प विचार है। वे कॉलबैक मेरे लिए मेरी कैशिंग क्लास कह सकते हैं!

— Xeoncross

Answer 11

PHP के कैशिंग एक्सटेंशन पर सलाह के लिए धन्यवाद - क्या आप एक के बाद एक का उपयोग करने के कारणों की व्याख्या कर सकते हैं? मैंने आईआरसी के माध्यम से मेमकेच के बारे में बहुत अच्छी बातें सुनी हैं, लेकिन एपीसी के बारे में कभी नहीं सुना है - उन पर आपकी क्या राय है? मुझे लगता है कि कई कैशिंग सिस्टम का उपयोग करना बहुत ही प्रभावी है।

दरअसल, कई APC का उपयोग करते हैं और एक साथ मेमेकैच्ड होते हैं ...

Answer 12

ऐसा लग रहा है कि मैं गलत था । MySQLi अभी भी विकसित किया जा रहा है। लेकिन लेख के अनुसार, PDO_MySQL का योगदान अब MySQL टीम द्वारा किया जा रहा है। लेख से:

MySQL इम्प्रूव्ड एक्सटेंशन - mysqli - प्रमुख है। यह MySQL सर्वर की सभी विशेषताओं का समर्थन करता है जिसमें चार्ट, तैयार किए गए विवरण और संग्रहीत कार्यविधियाँ शामिल हैं। ड्राइवर एक हाइब्रिड एपीआई प्रदान करता है: आप अपनी पसंद के आधार पर एक प्रक्रियात्मक या वस्तु-उन्मुख प्रोग्रामिंग शैली का उपयोग कर सकते हैं। mysqli PHP 5 और ऊपर के साथ आता है। ध्यान दें कि PHP 4 के लिए जीवन का अंत 2008-08-08 है।

PHP डेटा ऑब्जेक्ट (PDO) एक डेटाबेस एक्सेस एब्सट्रैक्शन लेयर है। पीडीओ आपको विभिन्न डेटाबेस के लिए एक ही एपीआई कॉल का उपयोग करने की अनुमति देता है। पीडीओ एसक्यूएल अमूर्त की कोई डिग्री प्रदान नहीं करता है। PDO_MYSQL PDO के लिए एक MySQL ड्राइवर है। PDO_MYSQL PHP 5 के साथ आता है। PHP 5.3 MySQL डेवलपर्स के रूप में सक्रिय रूप से इसमें योगदान करते हैं। यूनिफाइड एपीआई का पीडीओ लाभ इस कीमत पर आता है कि MySQL के विशिष्ट फीचर्स, उदाहरण के लिए कई स्टेटमेंट, यूनिफाइड एपीआई के माध्यम से पूरी तरह से समर्थित नहीं हैं।

कृपया पहले प्रकाशित PHP के लिए MySQL ड्राइवर का उपयोग करना बंद करें: ext / mysql। 2004 में PHP 5 के साथ MySQL इम्प्रूव्ड एक्सटेंशन - mysqli - की शुरूआत के बाद से अभी भी सबसे पुराने ड्राइवर का उपयोग करने का कोई कारण नहीं है। ext / mysql चारसेट, तैयार स्टेटमेंट और स्टोर की गई प्रक्रियाओं का समर्थन नहीं करता है। यह MySQL 4.0 के फीचर सेट तक सीमित है। ध्यान दें कि MySQL 4.0 के लिए विस्तारित समर्थन 2008-12-31 पर समाप्त होता है। ऐसे पुराने सॉफ्टवेयर के फीचर सेट तक खुद को सीमित न रखें! Mysqli में अपग्रेड करें, Converting_to_MySQLi भी देखें। mysql हमारे दृष्टिकोण से केवल रखरखाव में है।

मेरे लिए, ऐसा लगता है कि लेख MySQLi के लिए पक्षपाती है। मुझे लगता है कि मैं पीडीओ के पक्षपाती हूं। मैं वास्तव में MySQLi पर PDO पसंद करता हूं। यह मेरे लिए सीधे आगे है। एपीआई अन्य भाषाओं के बहुत करीब है जो मैंने प्रोग्राम किए हैं। ओओ डेटाबेस इंटरफेस बेहतर काम करते हैं।

मैं किसी भी विशिष्ट MySQL सुविधाओं में नहीं आया हूँ जो पीडीओ के माध्यम से उपलब्ध नहीं थे। मुझे आश्चर्य होगा अगर मैंने कभी किया।

Answer 13

पीडीओ भी बहुत धीमा है और इसका एपीआई बहुत जटिल है। अगर पोर्टेबिलिटी की चिंता नहीं है तो उनके समझदार दिमाग में किसी को भी इसका इस्तेमाल नहीं करना चाहिए। और चलो इसे सामना करते हैं, 99% में सभी webapps यह नहीं है। आप सिर्फ MySQL या PostrgreSQL के साथ चिपके रहते हैं, या आप जो भी हैं उसके साथ काम कर रहे हैं।

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

Answer 14

ज़रूर पीडीओ अच्छा है, लेकिन वहाँ है किया गया कुछ , हालांकि यह अब तय लगता है mysql और mysqli बनाम यह प्रदर्शन के बारे में विवाद,।

यदि आप पोर्टेबिलिटी की कल्पना करते हैं, तो आपको pdo का उपयोग करना चाहिए, लेकिन यदि नहीं, तो mysqli का तरीका होना चाहिए। इसमें एक OO इंटरफ़ेस, तैयार किए गए स्टेटमेंट, और अधिकांश जो pdo प्रदान करता है (छोड़कर, अच्छी तरह से, पोर्टेबिलिटी) है।

इसके अलावा, यदि प्रदर्शन वास्तव में आवश्यक है, तो PHP 5.3 में मूल निवासी (mysql) MysqLnd ड्राइवर की तैयारी करें , जो बेहतर प्रदर्शन और बेहतर मेमोरी उपयोग (और प्रदर्शन ट्यूनिंग के लिए आँकड़े) के साथ php के साथ बहुत अधिक मजबूती से एकीकृत होगा।

यदि आपके पास क्लस्टर सर्वर (और YouTube जैसे लोड) हैं, तो मेकैच अच्छा है, लेकिन मैं पहले APC को भी आज़माऊंगा ।

Answer 15

बहुत सारे अच्छे जवाब पहले से ही दिए गए थे, लेकिन मैं आपको XCache नामक एक वैकल्पिक ओपेक कैश पर इंगित करना चाहता हूं । यह एक हल्के योगदानकर्ता द्वारा बनाया गया है।

इसके अलावा, अगर आपको भविष्य में अपने डेटाबेस सर्वर को संतुलित करने की आवश्यकता हो सकती है, तो MySQL प्रॉक्सी आपको इसे प्राप्त करने में बहुत अच्छी तरह से मदद कर सकता है।

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

Answer 16

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

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

इस स्तर पर विभिन्न डेटाबेस नोड्स में अपने डेटा को विभाजित करना एक बहुत बुरा विचार है - हालांकि आप इसे एक ही सर्वर पर अलग-अलग डेटाबेस में विभाजित करने पर विचार कर सकते हैं (जो फेसबुक से आगे निकलते समय नोड्स में विभाजन की सुविधा प्रदान करेगा)।

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

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

एक ऑप-कोड कैश का उपयोग करें।

अपनी साइट और इसके लॉग का अध्ययन करने में बहुत समय व्यतीत करें, यह समझने के लिए कि इसकी गति इतनी धीमी क्यों है।

क्लाइंट पर जितना संभव हो उतना कैशिंग पुश करें।

आप जो कुछ भी कर सकते हैं उसे कंप्रेस करने के लिए mod_gzip का उपयोग करें।

सी।

Answer 17

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

सामान्य तौर पर, सरल तेज है । टेम्प्लेट आपको धीमा करते हैं। डेटाबेस आपको धीमा करते हैं। जटिल पुस्तकालय आपको धीमा करते हैं। डेटाबेस से उन्हें प्राप्त करने और एक जटिल पुस्तकालय में इसे पार्स करने पर एक-दूसरे पर टेम्प्लेट करना -> समय एक-दूसरे के साथ गुणा करना।

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

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

Answer 18

@ गैरी

MySQLi का उपयोग न करें - PDO 'आधुनिक' OO डेटाबेस एक्सेस लेयर है। उपयोग करने के लिए सबसे महत्वपूर्ण विशेषता आपके प्रश्नों में प्लेसहोल्डर है। यह आपके लिए सर्वर साइड तैयारियों और अन्य अनुकूलन का उपयोग करने के लिए पर्याप्त स्मार्ट है।

मैं इस समय PDO पर मज़ाक कर रहा हूँ और ऐसा लगता है कि आप सही हैं - हालाँकि मुझे पता है कि MySQL PHP के लिए MySQLd एक्सटेंशन को विकसित कर रहा है - मुझे लगता है कि या तो MySQL या MySQLi को सफल करना है - आप इसके बारे में क्या सोचते हैं?

---

@ रयान , एरिक , tj9991

PHP के कैशिंग एक्सटेंशन पर सलाह के लिए धन्यवाद - क्या आप एक के बाद एक का उपयोग करने के कारणों की व्याख्या कर सकते हैं? मैंने आईआरसी के माध्यम से मेमकेच के बारे में बहुत अच्छी बातें सुनी हैं, लेकिन एपीसी के बारे में कभी नहीं सुना है - उन पर आपकी क्या राय है? मुझे लगता है कि कई कैशिंग सिस्टम का उपयोग करना बहुत ही प्रभावी है।

मैं निश्चित रूप से कुछ प्रोफाइलिंग टेस्टर्स को हल कर रहा हूं - उन पर आपकी सिफारिशों के लिए बहुत-बहुत धन्यवाद।

Answer 19

मैं अपने आप को कभी भी MySQL से स्विच करते हुए नहीं देखता - इसलिए मुझे लगता है कि मुझे पीडीओ की अमूर्त क्षमताओं की आवश्यकता नहीं है। उन लेखों के लिए धन्यवाद DavidM, उन्होंने मेरी बहुत मदद की है।

Answer 20

में देखो mod_cache , Apache वेब सर्वर के लिए एक आउटपुट कैश, ASP.NET में उत्पादन कैशिंग करने के लिए simillar।

हां, मैं देख सकता हूं कि यह अभी भी प्रायोगिक है लेकिन यह किसी दिन अंतिम होगा।

Answer 21

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

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

अंत में, स्मृति-गहन संचालन से सावधान रहें, उदाहरण के लिए, अनावश्यक स्ट्रिंग प्रतिलिपि। यदि आप PHP की मेमोरी के उपयोग को कम रख सकते हैं, तो आपको अपने वेबसर्वर से अधिक प्रदर्शन प्राप्त होगा और यह कुछ ऐसा है जो जब आप लोड-संतुलित समाधान पर जाते हैं, तो स्केल होगा।

Answer 22

यदि आप बड़ी मात्रा में डेटा के साथ काम कर रहे हैं, और कैशिंग इसे काट नहीं रहा है, तो स्फिंक्स में देखें। हमारे पास बेहतर पाठ खोज के लिए न केवल SphinxSearch का उपयोग करने के साथ शानदार परिणाम हैं, बल्कि बड़ी तालिकाओं से निपटने के दौरान MySQL के लिए डेटा पुनर्प्राप्ति प्रतिस्थापन के रूप में भी। यदि आप SphinxSE (MySQL प्लगइन) का उपयोग करते हैं, तो यह हमारे प्रदर्शन लाभ को पार कर गया जो हमने कई बार कैशिंग से किया था, और अनुप्रयोग-कार्यान्वयन एक पाप है।

Answer 23

कैश के बारे में किए गए बिंदु स्पॉट-ऑन हैं; यह एक कुशल अनुप्रयोग के निर्माण का सबसे कम जटिल और सबसे महत्वपूर्ण हिस्सा है। मैं यह जोड़ना चाहूंगा कि जब मेमेकैट्स बढ़िया है, तो एपीसी लगभग पांच गुना तेजी से होता है यदि आपका आवेदन किसी एकल सर्वर पर रहता है।

MySQL के प्रदर्शन ब्लॉग पर "कैश प्रदर्शन तुलनात्मक" पोस्ट में विषय पर कुछ दिलचस्प मानक हैं - http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/ ।