PHP वेबसाइट ऑप्टिमाइज़ेशन

Question

मेरे पास एक उच्च ट्रैफ़िक वेबसाइट है और मुझे यह सुनिश्चित करने की ज़रूरत है कि मेरी साइट तेजी से मेरे पृष्ठों को सभी को प्रदर्शित करने के लिए पर्याप्त तेज़ है।

मैं गति और अनुकूलन के बारे में गूगल कई लेख पर खोज की है और यहाँ मैं क्या पाया है:

• कैश पेज
• यह सहेजें डिस्क

स्मृति में पृष्ठ कैशिंग करने के लिए:

यह बहुत तेज़ है लेकिन अगर मुझे अपने पृष्ठ की सामग्री को बदलने की ज़रूरत है तो मुझे इसे कैश से हटा देना होगा और फिर डिस्क पर फ़ाइल को फिर से सहेजें।

डिस्क

यह बहुत आसान बनाए रखने के लिए है, लेकिन हर बार पेज पर पहुंचने पर मैं डिस्क पर पढ़ने के लिए करने के लिए इसे सहेजें ।

मुझे किस विधि के साथ जाना चाहिए?

Answer 1

जनवरी & IDM ठीक कह रहे हैं, लेकिन यहाँ कैसे की जाती हैं:

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

आप एक PHP गतिवर्धक उपयोग कर सकते हैं यदि आप डायनामिक सामग्री को चलाने के लिए की जरूरत है:

What is the best PHP accelerator to use?

PHP Accelerators : APC vs Zend vs XCache with Zend Framework

:

मेरे सिफारिश Alternative PHP Cache (APC)

यहाँ उपयोग करने के लिए है कुछ बेंचमार्क है

Lighttpd – PHP Acceleration Benchmarks

कैशिंग सामग्री और यहां तक ​​कि पृष्ठों का उपयोग करने के लिए आप उपयोग कर सकते हैं: Memcached या Redis।

Memcached: नि: शुल्क & खुला स्रोत, उच्च प्रदर्शन, वितरित स्मृति वस्तु संचय सिस्टम, प्रकृति में सामान्य है, लेकिन डेटाबेस लोड को समाप्त करने से गतिशील वेब अनुप्रयोगों को तेज करने में इस्तेमाल के इरादे। Memcached डेटाबेस कॉल, एपीआई कॉल, या पेज प्रतिपादन के परिणामों से मनमानी डेटा (तार, वस्तुओं) के छोटे हिस्सों के लिए एक इन-मेमोरी कुंजी-मूल्य स्टोर है।

रेडिस रेडिस एक खुला स्रोत, उन्नत कुंजी-मूल्य स्टोर है। इसे अक्सर डेटा स्ट्रक्चर सर्वर के रूप में जाना जाता है क्योंकि कुंजी में तार, हैंश, सूचियां, सेट और सॉर्ट किए गए सेट हो सकते हैं।

सामग्री या चर को कैशिंग करने के लिए दोनों बहुत अच्छे उपकरण हैं।

यहाँ कुछ बेंचमार्क है और आप चुन सकते हैं कि आप पसंद करते हैं:

Redis vs Memcached

Redis vs Memcached

Redis VS Memcached (slightly better bench)

On Redis, Memcached, Speed, Benchmarks and The Toilet

Y कहां स्थापित कर सकते हैं भी Varnish, nginx, या G-Wan

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

nginx nginx (सुनाया? इंजन-x?) एक हल्के, उच्च प्रदर्शन वेब सर्वर/रिवर्स प्रॉक्सी और ई-मेल (IMAP/POP3) प्रॉक्सी, एक बीएसडी की तरह लाइसेंस के अंतर्गत लाइसेंस है। यह यूनिक्स, लिनक्स, बीएसडी वेरिएंट, मैक ओएस एक्स, सोलारिस और माइक्रोसॉफ्ट विंडोज पर चलता है।

जी वान जी वान एएनएसआई सी स्क्रिप्ट और मुख्य-मान की दुकान है जो सभी अन्य समाधान मात के साथ एक वेब सर्वर है।

यहाँ कुछ बेंचमार्क है और आप चुन सकते हैं कि आप पसंद करते हैं:

Serving static files: a comparison between Apache, Nginx, Varnish and G-WAN

Web Server Performance Benchmarks

Nginx+Varnish compared to Nginx

Apache, Varnish, nginx and lighttpd

G-WAN vs Nginx

Answer 2

आपके पास एक अच्छा विचार है, जो कि मैं अपने आप के करीब हूं। अगर मेरे पास एक पृष्ठ है जो 100% स्थिर है, तो मैं इसका एक HTML संस्करण सहेजूंगा और सामग्री को हर बार फिर से उत्पन्न करने के बजाय उपयोगकर्ता को सेवा दूंगा। यह कुछ मामलों में mysql क्वेरी और कई आईओ संचालन दोनों बचाता है। हर बार जब मैं कुछ बदलाव करता हूं, तो मेरा प्रशासन इंटरफ़ेस बस HTML फ़ाइल को हटा देता है और इसे पुन: प्रयास करता है।

यह विधि मेरे सर्वर पर लगभग 100x तेज साबित हुई है।

Answer 3

मैं जोड़ सकते हैं:

• कैश सब कुछ आप

• संख्या को न्यूनतम कर सकते हैं शामिल की

• त्वरक उपयोग

कृपया, जांच, क्या आपकी साइट बनाता है धीमी गति से। YSlow और इसी तरह की चीजों के बारे में मत भूलना, वे आपकी बहुत मदद कर सकते हैं।

इसके अलावा, अगर आप भारी गणना की है कि आप उनके लिए php विस्तार लिख सकता है, लेकिन मुझे नहीं लगता यह अपने मामले है

Answer 4

वेबसाइट प्रदर्शन के साथ बड़ा सवाल यह है कि "क्या आप स्थिर पृष्ठों की सेवा करते हैं, या आप गतिशील पृष्ठों की सेवा करते हैं?"।

स्टेटिक पृष्ठों

स्थैतिक पृष्ठों तेजी लाने के लिए सबसे अच्छा तरीका उन्हें अपनी वेबसाइट के बाहर कैश करने के लिए है। यदि आप बर्दाश्त कर सकते हैं, तो उन्हें सीडीएन (अकामाई, कोटेन्डो, लेवल 3) से सेवा दें। इस मामले में, यातायात कभी भी आपकी साइट को हिट नहीं करता है। कैश को नियंत्रित करने के कई तरीके हैं - निश्चित अवधि से मानक HTTP कैश निर्देशों तक।

भले ही आप सीडीएन से अपने एचटीएमएल की सेवा नहीं कर सकते हैं, सीडीएन पर अपनी छवियों, जावास्क्रिप्ट और अन्य स्थैतिक संपत्तियों को संग्रहीत करने से आपकी साइट तेज हो सकती है - आप इसके लिए अमेज़ॅन जैसी क्लाउड सेवा का उपयोग कर सकते हैं।

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

गतिशील पृष्ठों

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

यदि आपको विश्वास है कि आपकी बाधा डेटाबेस है, तो कैशिंग विकल्पों के कई तरीके हैं - आप HTML के "स्निपेट" को कैश कर सकते हैं, या आप डेटाबेस क्वेरी को कैश कर सकते हैं। एक त्वरक का उपयोग इस के साथ मदद करता है - मैं स्क्रैच से एक का आविष्कार नहीं करता। इसका शायद आपके आवेदन को पुन: आर्किटेक्टिंग (भागों) का मतलब है।

Answer 5

आपको अपनी साइट को पहले प्रोफ़ाइल करना होगा।

जंगली अनुमान के बजाय किसी को कुछ बाधाओं को निर्धारित करना होगा और फिर उस समस्या को हल करना होगा।

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

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