2009-02-20 13 views
5

मैं ज़ेंड फ्रेमवर्क के साथ PHP का उपयोग कर रहा हूं और डेटाबेस कनेक्ट अकेले 0,02 सेकेंड से अधिक समय लेता है जो Google एक क्वेरी करने के लिए लेता है। आज की डरावनी चीज मैंने एक वीडियो देखा जिसने कहा कि Google एक ही क्वेरी के लिए 1000 सर्वर से कनेक्ट करता है। विलंबता के साथ मैं अलग-अलग डेटासेंटर हैंडलिंग सामग्री में एकाधिक सर्वर होने की तुलना में प्रत्येक क्वेरी के लिए एक सर्वर की अपेक्षा अधिक प्रभावशाली होने की अपेक्षा करता हूं।Google को php के साथ गति कैसे प्राप्त करें?

मैं एक साथ काम करने और समान गति तक पहुंचने के लिए PHP, MySQL और Zend फ्रेमवर्क कैसे प्राप्त करूं?

एकमात्र तरीका कैशिंग है? "रेंडर" करने में कम समय लेने के लिए आप अपने कोड को कैसे अनुकूलित करते हैं।

+0

यह PHP और MySQL के साथ नहीं किया जा सकता है ... –

+0

200ms = 0.2 सेकंड btw। आप * * * php में करने में सक्षम होना चाहिए? – krosenvold

+0

सबसे पहले, वह समय है जब Google पृष्ठ (conect, query, echo ...) उत्पन्न करने के लिए लिया गया वास्तविक समय प्रदर्शित करता है या क्या वह क्वेरी करने के लिए बस इतना समय लगता है? मेरा मानना ​​है कि यह सिर्फ सवाल है। मेरे पास कई पेज हैं जो पूरे पृष्ठ को लोड करने के लिए 0.05 सेकंड लेते हैं। –

उत्तर

5

कुछ समय पहले Google ने सबकुछ रैम में डालने का फैसला किया था।

http://googlesystem.blogspot.com/2009/02/machines-search-results-google-query.html

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

+0

मैं कैसे जांचूं कि मेरा डीबी रैम में पूरी तरह से है या नहीं? – Thomaschaaf

+0

Google अपने डीबी इंजन का उपयोग कर रहा है, मुझे संदेह होगा। मुझे नहीं लगता कि आप पूरे डेटाबेस को रैम में रखने के लिए MySQL को मजबूर कर सकते हैं। –

+0

आप हमेशा MySQL क्लस्टर का उपयोग कर सकते हैं! डिस्क पर कभी-कभी चेकपॉइंट के साथ यह सब रैम पर जाता है। हालांकि, सेटअप करने के लिए बहुत उन्नत है। आप सभी मेमोरी टेबल का भी उपयोग कर सकते हैं, लेकिन 'पोफ!' अगर सर्वर नीचे चला जाता है। – jonstjohn

8

ऐसी कई तकनीकें हैं जिनका उपयोग Google द्वारा प्रदान किए जाने वाले थ्रूपुट की मात्रा को प्राप्त करने के लिए करता है। MapReduce, Google File System, BigTable उनमें से कुछ हैं।

में कुछ बहुत अच्छा नि: शुल्क & मुक्त स्रोत इन के लिए विकल्प, अर्थात् Apache Hadoop, Apache HBase और Hypertable रहे हैं। याहू! हैडोप परियोजनाओं का बहुत उपयोग और प्रचार कर रहा है और इस प्रकार वे काफी सक्रिय रूप से बनाए रखा जाता है।

+0

क्या अच्छे विकल्प हैं? – Thomaschaaf

+0

मैंने कुछ अच्छे विकल्पों को जोड़ने के लिए अपना जवाब संपादित किया है। –

+0

धन्यवाद। (मुझे यहां कुछ लिखना है) – Thomaschaaf

3

यह वास्तव में आप क्या करने की कोशिश कर रहे हैं पर निर्भर करता है, लेकिन यहां कुछ उदाहरण:

  • समझाने के साथ अपने प्रश्नों का विश्लेषण करें। अपने देव पर्यावरण में आप पृष्ठ के निचले हिस्से में अपने प्रश्नों और निष्पादन समय को आउटपुट कर सकते हैं - प्रश्नों की संख्या को कम करें और/या धीमी गति से अनुकूलित करें।

  • एक कैशिंग परत का उपयोग करें। ऐसा लगता है कि ज़ेंड को memcache सक्षम किया जा सकता है। यह डीबी की बजाय अल्ट्रा-फास्ट कैशिंग परत को अनुरोध भेजकर संभावित रूप से आपके एप्लिकेशन को तेज़ी से बढ़ा सकता है।

  • अपने फ्रंट-एंड लोडिंग समय को देखें। फ़ायरबग में याहू के वाईएसलो ऐड-ऑन का प्रयोग करें। Http अनुरोधों को सीमित करें, जेएस, सीएसएस और छवियों को कैश करने के लिए दूर-भविष्य के शीर्षलेख सेट करें। आदि

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

1

यदि यह एक खोज इंजन के लिए है, तो बाधा डेटाबेस के आकार के आधार पर डेटाबेस है।

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

0

@ कोल्टिन द्वारा प्रदान किए गए लिंक के अनुसार, Google प्रतिक्रिया समय 2 सेकंड के क्षेत्र में हैं , नहीं .02 सेकंड।जब तक आपके एप्लिकेशन में एक कुशल डिज़ाइन है, मुझे विश्वास है कि आपको इसे कई प्लेटफ़ॉर्म पर प्राप्त करने में सक्षम होना चाहिए। हालांकि मुझे PHP नहीं पता है, लेकिन अगर मुझे 2 सेकंड एक समस्या है तो मुझे आश्चर्यचकित कर देगा।

2

Memcached लिनक्स पर स्मृति में भंडारण/पुनर्प्राप्ति को अनुकूलित करने के लिए एक अनुशंसित समाधान है।

6

मैं Zend फ्रेमवर्क साथ PHP का उपयोग कर रहा हूँ और डाटाबेस अकेले जोड़ता है 0,02 सेकंड गूगल एक प्रश्न करने के लिए ले जाता है से अधिक समय लग करने लगते हैं।

डेटाबेस कनेक्ट ऑपरेशंस हेवीवेट हैं चाहे आप कौन हैं: कनेक्शन पूल का उपयोग करें ताकि आपको प्रत्येक अनुरोध के लिए संसाधन प्रारंभ करने की आवश्यकता न हो।

प्रदर्शन आर्किटेक्चर भाषा नहीं है।

+0

सत्य के लिए +1 "प्रदर्शन वास्तुकला के बारे में भाषा नहीं है"। मुझे इन सवालों से नफरत है: पी –

1

Google में एक विशाल, अत्यधिक वितरित प्रणाली है जिसमें बहुत से स्वामित्व वाली तकनीक (अपने हार्डवेयर, और ऑपरेटिंग, फ़ाइल और डेटाबेस सिस्टम सहित) शामिल है।

सवाल यह पूछने जैसा है: "मैं अपनी कार को ट्रक कैसे बना सकता हूं?" और अनिवार्य रूप से अर्थहीन।

+0

मुझे उचित प्रतिक्रिया की तरह लगता है - अन-डाउनवॉटेड। –

0
  • एपीसी कोड कैशिंग;
  • एपीसी या मेमकैच बैकएंड के साथ Zend_Cache;
  • स्थिर फ़ाइलों के लिए सीडीएन;
2

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

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

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

वास्तविक "समस्या" यह है कि PHP अन्य ढांचे की तुलना में थोड़ा अलग काम करता है, क्योंकि यह एक एसएसआई (सर्वर-साइड शामिल) तरीके से काम करता है - प्रत्येक अनुरोध http सर्वर द्वारा संभाला जाता है और यदि इसे एक PHP स्क्रिप्ट चलाने की आवश्यकता होती है, इसका दुभाषिया प्रारंभ किया गया है और स्क्रिप्ट लोड, पार्स, संकलित और चलाया जाता है। इसकी तुलना कार से होकर, इंजन शुरू करने और 10 मीटर के लिए जा रही है।

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

उपरोक्त कैशिंग/प्रीकंपलिंग और पूलिंग समाधान इनिट ओवरहेड को कम करने में सबसे अच्छे हैं।PHP/MySQL अभी भी एक आरडीबीएमएस आधारित समाधान है, और एक अच्छा कारण है कि बिगटेबल क्यों है, ठीक है, केवल एक बड़ा, शर्मीला, बड़े पैमाने पर वितरित हैशटेबल (oversimplification का थोड़ा सा, मुझे पता है) - High Scalability पर पढ़ें।

संबंधित मुद्दे