2009-05-01 21 views
6

मैं एक आभूषण थोक व्यापारी के लिए एक वेबसाइट चला रहा हूं।MySQL संग्रहीत प्रक्रिया बनाम PHP स्क्रिप्ट

उनके सभी उत्पादों की कीमतें वर्तमान बॉलियन धातु फिक्स का उपयोग करके गणना की जाती हैं जो हर रात अपडेट की जाती हैं।

वर्तमान में, वेबसाइट के लिए, गणना एक php के माध्यम से काम की जाती है जिसमें फ़ंक्शन शामिल है, जो वर्तमान परिस्थितियों में ठीक काम करता है।

लगभग 10,000 उत्पाद हैं, लेकिन कीमतें वास्तविक समय में गणना की जाती हैं (यानी जब वेब पेज का अनुरोध किया जाता है)। गणना सरल होती है, लेकिन उनमें से बहुत से (लगभग 50+) हैं और मुझे चिंता है कि यातायात में वृद्धि मौजूदा स्क्रिप्ट को धीमा कर सकती है।

मैं साइट को फिर से डिजाइन कर रहा हूं और सोच रहा था कि इसके बजाय गणना करने के लिए MySQL में प्रक्रिया बनाने के लिए फायदेमंद होगा या नहीं।

क्या यह संभव है कि वर्तमान PHP स्क्रिप्ट? किसी को भी प्रक्रियाओं का उपयोग करने पर कोई अच्छा पढ़ने संदर्भ पता है?

+0

सभी टिप्पणियों और लिंक के लिए धन्यवाद। मुझे लगता है कि मैं इसे बदलने के भविष्य के सिरदर्दों पर विचार करने के दृष्टिकोण को "अगर इसे तोड़ा नहीं है, तो इसे ठीक न करें" दृष्टिकोण ले लेंगे। – ticallian

+2

मेरे उत्तर को कम करने वाले किसी भी व्यक्ति के लिए, क्या आप कृपया विस्तार से बता सकते हैं? मुझे विश्वास है कि यह एक वैध जवाब है। – Unknown

उत्तर

4

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

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

प्रदर्शन पहलू के अलावा, मैं अभी भी आम तौर पर आवेदन क्योंकि

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

यदि आप संग्रहित प्रक्रियाओं का उपयोग करना चाहते हैं, तो इन समस्याओं को सभी कठिनाई के बिना हल किया जा सकता है।

10

यहां संग्रहीत प्रक्रिया बनाम php के साथ एक बेंचमार्क है।

http://mtocker.livejournal.com/45222.html

संग्रहीत प्रक्रिया 10x द्वारा धीमी थी।

आप भी इस को देखने के लिए चाहते हो सकता है:

http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html

+1

यह सुनिश्चित नहीं है कि यह क्यों कम किया गया था। हालांकि मुझे उस बेंचमार्क की सटीकता के बारे में संदेह है। – thomasrutter

+0

मुझे या तो नहीं पता, मुझे वैध उत्तरों के लिए पूरे दिन डाउनवॉट किया गया है। – Unknown

+4

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

3

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

मैं आपके द्वारा उपयोग की जाने वाली जानकारी को कैश करने की अनुशंसा करता हूं (और यह जानने के बिना विस्तार करना मुश्किल है कि आप इसे कैसे कर रहे हैं) स्मृति में (शायद memcached का उपयोग करके) और PHP से इसे पढ़ते रहें।

मैं स्वीकार करूंगा कि मैंने संग्रहित प्रक्रियाओं के बीच मेमोरी PHP प्रदर्शन के बीच कोई बेंचमार्किंग नहीं की है, लेकिन यदि प्रक्रिया सीधे आपकी क्वेरी को प्रभावित नहीं करती है, तो मैं कैशिंग की अनुशंसा करता हूं।

+0

memcached का उपयोग करने के बारे में अच्छी युक्ति – thomasrutter

2

संक्षेप में, उन्हें php में रखें। बनाए रखने के लिए आसान है।

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

यह कहकर, PHP में कैल्क को आमतौर पर पसंद किया जाता है क्योंकि इसे नियंत्रित करना और डीबग करना आसान होता है। इसके लिए वेब कोडर को डेटाबेस को कुछ हद तक जानने की आवश्यकता होती है लेकिन यह आमतौर पर कोई समस्या नहीं है। 9 0% कोड स्पीड अप कोड के 10% पर होते हैं और डीबीए के लिए डीबी लोड के कारण पूछे जाने वाले प्रश्नों की पहचान करना काफी आसान होगा।

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