"PHP स्क्रिप्ट के अनुकूलन पर युक्तियों और तथ्यों के संग्रह" के नक्शेकदम पर चलें

कल, पोस्ट पढ़ने के बाद " PHP स्क्रिप्ट के अनुकूलन पर युक्तियों और तथ्यों का एक संग्रह, " लेख में कुछ बिंदुओं पर मुझे नुकसान हुआ था। बहुत बार, काम पर, आपको बड़ी परियोजनाओं से निपटना पड़ता है। पिछले 5 वर्षों से मैं उच्च भार के साथ काम कर रहा हूं और मुझे ऐसा लगता है, उनके विकास और समर्थन में अच्छा अनुभव प्राप्त किया है। मैं होलीवर्स शुरू नहीं करना चाहता और परियोजना अनुकूलन के सभी विवरणों को विवरण में चित्रित करना चाहता हूं। मैं लेख में व्यक्त किए गए कुछ बिंदुओं पर अपना दृष्टिकोण व्यक्त करना चाहता हूं और, अगर हैबरूसर मेरा समर्थन करता है, तो बहुत खुशी के साथ यह लेख अनुकूलन पर लेखों की एक श्रृंखला की शुरुआत होगी।



अनुकूलन करते समय याद रखने वाला सबसे महत्वपूर्ण नियम: समयपूर्व अनुकूलन सभी बीमारियों की जड़ है।

अनुकूलन युक्तियाँ

स्पष्ट कोड अनुकूलित की तुलना में 99% बेहतर है

• बहुत बार, आपके द्वारा लिखा गया कोड किसी और द्वारा उपयोग किया जाएगा, और आपके कोड को समझने में लगने वाला समय बहुत महत्वपूर्ण होगा
• एक अलग वर्ग के तहत एक अलग फ़ाइल बनाने का प्रयास करें
  
  हां, आप आवश्यकता की संख्या बढ़ाएँगे (शामिल करें, requirement_once, शामिल_ऑनस), लेकिन किसी विशेष वर्ग को ढूंढना कई गुना आसान होगा
• कक्षाओं और चर के लिए छोटे नामों का उपयोग करने का प्रयास न करें।
  
  यदि $ वीडियो के बजाय आप चर $ a का नाम लेते हैं, तो गति में लाभ हास्यास्पद होगा, लेकिन कोड को तेजी से समझना और एक त्रुटि की संभावना है जो पकड़ना मुश्किल है, बढ़ जाएगी।
• यदि गति वास्तव में आपके लिए मायने रखती है, तो उत्पादन के लिए अपने कोड का एक सरल स्क्रिप्ट-कंपाइलर लिखें (आप संकलन संकलन की दिशा में भी देख सकते हैं)
  
  लेकिन याद रखें कि इस मामले में, यदि उत्पादन पर कोई समस्या है, तो डिबग करना कठिन होगा (यदि आप उदाहरण के लिए चर का नाम बदलते हैं)

एक जटिल से कई सरल प्रश्नों को कैश करना आसान है

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

डेटाबेस से आपके पास आने वाले सभी डेटा को कैश करने का प्रयास करें

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

वास्तुकला युक्तियाँ

• स्थैतिक सामग्री को प्रस्तुत करने के लिए nginx या lighttpd का उपयोग करें
• PHP को तेज करने के लिए, आप उदाहरण के लिए eAccelerator का उपयोग कर सकते हैं
• गज़िप का प्रयोग करें
• एक में js और css फाइलों को मिलाएं
  
  इन फ़ाइलों की मात्रा कम करने के लिए विभिन्न कंप्रेशर्स का उपयोग करना भी बहुत अच्छा है (Google बंद उपकरण, YUI कंप्रेसर और अन्य)

पीएस टॉपिक अभिनव होने का दावा नहीं करता है और केवल बड़ी परियोजनाओं के विकास के पक्ष से अनुकूलन पर एक नज़र है।

PPS यदि आप कर्म में नकारात्मक हैं, तो कम से कम टिप्पणियों में क्या लिखें।