2008-11-25 11 views
14

मैं एक फोरम इंजन में अवतार जोड़ रहा हूं जिसे मैं डिजाइन कर रहा हूं, और मैं बहस कर रहा हूं कि कुछ सरल करना है (फ़ोरम छवि का नाम .png है) और PHP का उपयोग यह जांचने के लिए करें कि फ़ाइल प्रदर्शित करने से पहले मौजूद है या नहीं कुछ और जटिल (लेकिन ज्यादा नहीं) और दिखाने के लिए छवि का नाम रखने के लिए डेटाबेस फ़ील्ड का उपयोग करें।PHP में file_exist() एक बहुत महंगा ऑपरेशन है?

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

यदि नहीं, तो अच्छा है। यदि ऐसा होता है, तो उपयोगकर्ता द्वारा अपलोड की गई छवि का ट्रैक रखने के विकल्पों पर आपकी राय क्या है? धन्यवाद!

पीएस: कोड अंतर मैं देख सकता हूं कि फाइल जांच संस्करण फाइलों को बात करने देता है, जबकि डेटाबेस फॉर्म ट्रस्ट करता है कि डेटाबेस सटीक है और जांच करने के लिए परेशान नहीं है। (यह सिर्फ एक यूआरएल है जो पाठ्यक्रम के ब्राउज़र में पास हो जाता है।)

उत्तर

12

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

हालांकि, यदि आप पहले ही डेटाबेस से उपयोगकर्ता की जानकारी पढ़ रहे हैं, तो आप वहां की जानकारी भी स्टोर कर सकते हैं। यदि उपयोगकर्ता को केवल एक अवतार की अनुमति है, तो आप "अवतार" (1/0) के लिए कॉलम में केवल एक बिट स्टोर कर सकते हैं, और उसके बाद फ़ाइल आईडी उपयोगकर्ता आईडी के समान ही हो सकती है, और SELECT CONCAT(IF(has_avatar, id, 'default'), '.png') AS avatar FROM users

जैसे कुछ का उपयोग करें

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

+0

कैश की जानकारी बहुत आश्वस्त है, मैं file_exists समाधान के साथ जा रहा हूं। हालांकि, बीएलओबी विचार बहुत दिलचस्प लग रहा है, मैं बस बाद में कोशिश कर सकता हूं। धन्यवाद! –

+6

लेकिन बीएलओबी प्रदर्शन के लिए अच्छा नहीं है। आप PHP, MySQL चलाने के ऊपरी हिस्से को प्राप्त करते हैं, और आपको HTTP कैश सत्यापन के लिए समर्थन लिखना होगा, अन्यथा ब्राउज़र अनावश्यक रूप से अवतार डाउनलोड करना जारी रखेंगे। – Kornel

+4

यह ध्यान रखना महत्वपूर्ण है कि PHP केवल उन फ़ाइलों के परिणामों को कैश करेगा जो मौजूद हैं, यह उन फ़ाइलों के परिणामों को कैश नहीं करेगा जो मौजूद नहीं हैं। देखें: http://www.php.net/manual/en/function.clearstatcache.php – Brian

7

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

  • एक
  • एक वेब जड़
  • प्रत्येक उपनिर्देशिका के लिए एक .htaccess फ़ाइल के लिए जाँच करने के लिए (अस्तित्व और सिमलिंक के लिए जाँच करने के लिए)
  • अपनी स्क्रिप्ट

इस के अस्तित्व के लिए एक उनमें से अधिक है कि PHP ही कर सकता पर विचार नहीं है।

0

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

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

0

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

"डिफ़ॉल्ट" अवतार के अनुसार ... अगर उस उपयोगकर्ता के लिए रिकॉर्ड नहीं मिला है, तो बस डिफ़ॉल्ट का उपयोग करें।

किसी भी तरह से, file_exists() या डीबी, इसके बारे में चिंता करने के लिए यह एक बाधा नहीं होनी चाहिए। एक समाधान, हालांकि, अधिक विस्तार योग्य है।

+0

आप नीचे आ गए हैं और मुझे यकीन नहीं है कि यह एक अच्छा जवाब क्यों है और मैंने कभी इसे अपने बारे में नहीं सोचा। –

+0

मैंने कुछ अनुयायियों को अपनाया है जो मैंने जो भी किया है उसे कम करें। –

+0

मैं सही उत्तर में टिप्पणी नहीं कर सकता, लेकिन एक और बात - ब्लॉग्स के रूप में छवियों को स्टोर न करें। यह वास्तव में खराब प्रदर्शन है।मेरा विश्वास करो, इस पर वेब पर विज्ञापन infinitum पर चर्चा की गई है। –

0

यदि प्रदर्शन आपका एकमात्र विचार है तो file_exists() डेटाबेस लुकअप के बाद बहुत कम महंगा होगा।

यह सब सिस्टम कॉल का उपयोग कर सिर्फ एक निर्देशिका लुकअप है। स्क्रिप्ट के पहले निष्पादन के बाद अधिकांश रिलीज निर्देशिका को भंडारण में कैश किया जाएगा, इसलिए बहुत कम वास्तविक I/O शामिल है, और, "file_exists()" ऐसा एक आम ऑपरेशन है कि यह और अंतर्निहित सिस्टम कॉल अत्यधिक होगी किसी भी सामान्य php/os संयोजन पर अनुकूलित।

जॉन II ने नोट किया। यदि अतिरिक्त कार्यक्षमता और उपयोगकर्ता इंटीफेस विशेषताएं प्राथमिकता हैं तो डेटाबेस जाने का तरीका होगा।

8

वास्तविक प्रदर्शन परीक्षण में, आप file_exists को बहुत तेज़ी से खोज पाएंगे। जैसा कि, php में, जब एक ही यूआरएल दो बार "stat" d है, तो दूसरा कॉल सिर्फ php के आंतरिक स्टेट कैश से खींचा जाता है।

और यह केवल PHP रन स्कोप में है। रनों के बीच भी, फाइल सिस्टम/ओएस फाइल को सिस्टम सिस्टम कैश में आक्रामक रूप से डाल देगा, और यदि फ़ाइल पर्याप्त छोटा है, न केवल फाइल मौजूद है, परीक्षण सीधे मेमोरी से बाहर आ जाएगा, लेकिन पूरी फाइल भी होगी।

मैं सिर्फ linux कमांड लाइन उपयोगिताओं के कुछ प्रदर्शन परीक्षणों कर रहा था "xargs" "ढूंढें" और:

यहाँ मेरी सिद्धांत वापस करने के लिए कुछ वास्तविक डेटा है। आय में, मैंने 13000 फाइलों पर एक फ़ाइल मौजूद है, 100 सेकंड के भीतर प्रत्येक 100 गुना, ताकि औसत प्रति 43,000 स्टेट टेस्ट औसत हो, तो निश्चित रूप से, ठीक पैमाने पर इसकी धीमी गति से यदि आप इसे कहने की तुलना करते हैं, तो समय यह 9 से 8 तक विभाजित होता है, लेकिन वास्तविक दुनिया परिदृश्य में, आपको एक उल्लेखनीय प्रदर्शन समस्या देखने के लिए भयानक कई बार ऐसा करने की आवश्यकता होगी।

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

1

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

यह संभव हो सकता है कि PHP5 में वे file_exists को कैश करें, लेकिन कम से कम PHP4 के साथ जो मामला नहीं था।

अब, यदि आप लूप में नहीं हैं, तो जाहिर है, file_exists एक बड़ा सौदा नहीं होगा।

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