2010-02-04 22 views
8

प्रश्न सं लगभग तुरंत एक निश्चित हाँ कहते हैं या करने के लिए कुछ लोगों को संकेत कर सकता है, लेकिन कृपया पर पढ़ें ...अनावश्यक PHP फ़ाइलों सहित वेबसाइट धीमा कर देगा?

मैं एक साधारण वेबसाइट है, जहां 30 php पृष्ठों (प्रत्येक कुछ php सर्वर साइड कोड है देखते हैं है + एचटीएमएल/सीएसएस आदि ...)। कोई जटिल पदानुक्रम, कुछ भी नहीं। बस 30 पेज।

मेरे पास पूरी तरह से बैक-एंड PHP फ़ाइलों का एक सेट भी है - जिनके पास डेटाबेस में सामान सहेजने के लिए कोड है, प्रमाणीकरण कर रहा है, ईमेल भेज रहा है, ऑर्डर प्रोसेसिंग और इसी तरह की है। इन 30 सामग्री-पृष्ठों द्वारा इनका पुन: उपयोग किया जाएगा।

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

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

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

पहला प्रश्न - क्या यह एक अच्छा अभ्यास है? अगर यह किसी के द्वारा किया जाता है।

दूसरा, क्या मेरी आवश्यकता के बावजूद सभी बैक-एंड फ़ाइलों सहित किसी प्रदर्शन समस्या या किसी भी तरह की समस्या होगी?

संपादित

वेबसाइट कहीं भी 3000 के बीच हो जाता है - 4000 का दौरा एक दिन।

+0

आप अलग-अलग कॉन्फ़िगरेशन में रनटाइम को मापने जैसे कुछ सरल प्रदर्शन परीक्षणों को आसानी से दूसरे प्रश्न का उत्तर दे सकते हैं ... – jochil

उत्तर

7

आपको बेंचमार्क करना चाहिए। अलग-अलग पृष्ठ के निष्पादन के समय में अलग-अलग शामिल हैं। लेकिन मुझे लगता है कि यह 30 फाइलों के साथ ज्यादा अंतर नहीं करेगा।

लेकिन आप स्वयं को समय बचा सकते हैं और php.ini में APC सक्षम कर सकते हैं (यह एक पीईसीएल एक्सटेंशन है, इसलिए आपको install इसे चाहिए)। यह आपकी फ़ाइलों की पार्स की गई सामग्री को कैश करेगा, जो चीजों को काफी तेज़ी से बढ़ाएगा।

Btw: आलस्य के साथ गलत कुछ भी नहीं है, यह भी एक virtue है;)

+0

हाय, एपीसी चीज का सुझाव देने के लिए धन्यवाद :) ऐसा लगता है कि यह आसान हो जाएगा ** अगर ** मैं फाइलों को शामिल करने के इस तरीके से चिपक जाता हूं। – thedeveloper

+0

बस एपीसी पर कुछ शोध किया और ऐसा लगता है कि मुझे इसकी आवश्यकता है। मैंने एपीसी स्थापित किया। इसके साथ और इसके बिना प्रोफाइल करना है। लेकिन जो लोग कहते हैं, उससे ध्यान देने योग्य प्रदर्शन मतभेदों पर ध्यान दिए बिना एक अच्छी बात है। – thedeveloper

1

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

+0

यहां तक ​​कि यदि मैं ऐसा करता हूं, तो कई साझा फ़ाइलों को शामिल करने में यह समस्या है। मुझे आशा है कि मैं समझ में आ रहा हूं। मान लें कि मैं प्रेजेंटेशन सामान हटा देता हूं। लेकिन व्यापार तर्क के पास PHP फाइलों का अपना सेट होगा।इन सभी बिज़ तर्क फ़ाइलों को सामान्य php फ़ाइलों की एक चर संख्या की आवश्यकता होगी। वही समस्या फिर से आती है। क्या होगा यदि मैं कुछ सामान्य फ़ाइलों को पुन: व्यवस्थित/जोड़/हटा/विलय करता हूं? मुझे प्रत्येक बिज़ तर्क php फ़ाइल पर जाना है और पथ शामिल करना है। अगर मुझे प्रदर्शन हिट का अच्छा विचार है, तो मैं एक विकल्प बना सकता हूं। – thedeveloper

1

यह एक बुरा व्यवहार नहीं है, तो फ़ाइलों छोटे हैं और सिर्फ परिभाषा और सेटिंग होती हैं। यदि वे वास्तव में कोड चलाते हैं, या बहुत बड़े हैं, तो यह एक प्रदर्शन समस्या का कारण बन जाएगा। अब - यदि आपकी साइट में 3 आगंतुक एक घंटे हैं - जो आपकी परवाह करते हैं, यदि आपके पास 30000 है ... यह एक और मुद्दा है, और आपको इसे कम करने के लिए कड़ी मेहनत करने की आवश्यकता है।

-1

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

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

0

आप XCache का उपयोग करके PHP कोड संकलन का नुकसान के कुछ migitate कर सकते हैं। यह PHP मॉड्यूल PHP-opcode को कैश करेगा जो संकलन समय और प्रदर्शन को कम करता है।

4

अपनी साइट है वस्तु उन्मुख अगर मैं ऑटो लोड हो रहा है (http://php.net/manual/en/language.oop5.autoload.php) का उपयोग की सलाह देते हैं।

यह आवश्यक होने पर कक्षा की तलाश करने के लिए एक जादू विधि (__autoload) का उपयोग करता है (यह आलसी है, बस आप की तरह!), इसलिए यदि किसी विशेष पृष्ठ को सभी कक्षाओं की आवश्यकता नहीं है, तो उन्हें उन्हें प्राप्त नहीं करना है !

फिर, हालांकि, इस पर निर्भर करता है अगर यह वस्तु उन्मुख या नहीं है ...

+0

अरे, धन्यवाद! :) मेरे कोड का एक बड़ा हिस्सा ओओ है। मैं लिंक देखूँगा .. – thedeveloper

+0

हालांकि मैं हर समय ऑटोलोड का उपयोग करता हूं (यह बहुत अच्छा है), जब गति एक मुद्दा है तो यह एक बुरी सलाह है। Autoload सब कुछ शामिल करने से धीमा तरीका है, और जब भी चीजें चुनिंदा रूप से शामिल होते हैं तब भी धीमे होते हैं। आखिरकार, यह __autoload का उपयोग करने के लिए एक बुरा अभ्यास है। इसके बजाय spl_autoload का प्रयोग करें। – Evert

0

अपनी वेबसाइट के आकार को देखते हुए; यदि आपने मंदी देखी नहीं है, तो इसे ठीक करने का प्रयास क्यों करें?

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

यदि प्रतिक्रिया-गति अभी भी समस्याग्रस्त है, तो आपको सभी अपनी फ़ाइलों को शामिल करने पर विचार करना चाहिए। एपीसी आपकी स्रोत फाइलों का कैश संस्करण स्मृति में रखेगा, लेकिन में कोई सशर्त नहीं होने पर में यह केवल तभी अच्छा हो सकता है।

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

रस्मुस लेर्दोर्फ़ (PHP के पीछे आदमी) इससे सहमत हैं: http://pooteeweet.org/blog/538

+0

अपनी पहली पंक्ति में प्रश्न का उत्तर देने के लिए - यदि मैं इस विधि में गहरी गर्दन हूं, और ** मार्केटिंग ** एक चमत्कार को खींचता है और फिर वेबसाइट को 50000 विज़िट मिलती हैं, तो मुझे परेशानी होगी। – thedeveloper

+0

500000 विज़िट अभी भी चिंता का कारण नहीं है। मैं उस मामले में वेबसर्वर कॉन्फ़िगरेशन और एसक्यूएल प्रश्नों जैसी चीजों पर समय बिताने का सुझाव देता हूं। – Evert

0

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

तो मुख्य मुद्दा यह है कि आप भी सभी शामिल फ़ाइलों के लिए पथ बदल रहा है (यदि पथ कभी भविष्य में अपडेट करने की आवश्यकता) जाने के लिए आलसी रहे हैं। फिर आप अपनी मुख्य फ़ाइल में पथ को परिभाषित करने के लिए निरंतर उपयोग कर सकते हैं, और फ़ाइल को शामिल/आवश्यक करने के लिए किसी भी समय निरंतर उपयोग कर सकते हैं।

define('PATH_TO_FILES', '/var/www/html/mysite/includes/go/in/here/'); 

require_once PATH_TO_FILES.'database.php'; 
require_once PATH_TO_FILES.'sessions.php'; 
require_once PATH_TO_FILES.'otherstuff.php'; 

इस तरह यदि पथ बदल जाता है, आप केवल कोड की एक पंक्ति को संशोधित करने की जरूरत है।

-1

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