कैश्ड, PHP ने थम्बनेल लोड को धीरे-धीरे उत्पन्न किया


179

प्रश्न भाग ए Main (100 बाउंटी, सम्मानित)
मुख्य प्रश्न यह था कि इस साइट को कैसे बनाया जाए, जो तेजी से लोड हो। पहले हमें इन झरनों को पढ़ने की जरूरत थी। झरना रीडआउट विश्लेषण पर आपके सुझावों के लिए धन्यवाद। यहां दिखाए गए विभिन्न जलप्रपात रेखांकन से स्पष्ट है कि मुख्य अड़चन है: PHP- जनरेटेड थंबनेल। डेविड द्वारा सलाह दी गई CDN से प्रोटोकॉल-कम jquery लोडिंग को मेरा इनाम मिला, हालांकि मेरी साइट को कुल मिलाकर केवल 3% तेजी से बनाया गया, और साइट की मुख्य अड़चन का जवाब नहीं दिया गया। मेरे प्रश्न के स्पष्टीकरण के लिए समय, और, एक और इनाम:

प्रश्न भाग B The (100 बाउंटी, सम्मानित)
नया ध्यान अब उस समस्या को हल करने के लिए था, जो 6 jpg चित्रों में थी, जो लोडिंग-विलंब का सबसे अधिक कारण हैं। ये 6 छवियां PHP द्वारा उत्पन्न थंबनेल, छोटी और केवल 3 ~ 5 केबी हैं, लेकिन अपेक्षाकृत बहुत धीरे-धीरे लोड हो रही हैं। सूचना " पहली बाइट के लिए समय विभिन्न रेखांकन पर"। समस्या अनसुलझी रही, लेकिन एक इनाम जेम्स के पास गया, जिसने हेडर त्रुटि को ठीक किया, जिसे RedBot ने रेखांकित किया : "एक इफ़ -संशोधित-चूंकि सशर्त अनुरोध ने पूर्ण सामग्री को अपरिवर्तित लौटा दिया।"

प्रश्न भाग C points (मेरा अंतिम बाउंटी: 250 अंक)
दुर्भाग्य से, REdbot.org हेडर की त्रुटि को ठीक करने के बाद भी, PHP द्वारा उत्पन्न छवियों के कारण देरी अछूती रही। पृथ्वी पर ये छोटे-छोटे पुण्य ३ ~ ५ केबी थंबनेल क्या सोच रहे हैं? हेडर की सभी जानकारी रॉकेट और चंद्रमा को भेज सकती है। इस अड़चन पर किसी भी सुझाव की बहुत सराहना की जाती है और संभव जवाब के रूप में माना जाता है, क्योंकि मैं पहले से ही सात महीने से इस अड़चन समस्या में फंस गया हूं। मेरा अग्रिम धन्यवाद।

[मेरी साइट पर कुछ पृष्ठभूमि की जानकारी: सीएसएस शीर्ष पर है। नीचे जेएस (Jquery, JQuery यूआई, मेनू awm / menu.js इंजन, टैब js इंजन, वीडियो swfobject.js) खरीदा दूसरी छवि पर काली रेखाएं दिखाती हैं कि क्या लोड करना है। गुस्से में रोबोट मेरा पालतू "ZAM" है। वह हानिरहित है और अक्सर खुश रहता है।]


भार जलप्रपात: कालानुक्रमिक | http://webpagetest.org यहां छवि विवरण दर्ज करें


समानांतर डोमेन समूहीकृत | http://webpagetest.org यहां छवि विवरण दर्ज करें


साइट-परफेक्ट झरना | http://site-perf.com यहां छवि विवरण दर्ज करें


पानी के नीचे के उपकरण झरना | http://tools.pingdom.com

यहां छवि विवरण दर्ज करें


GTmetrix झरना | http://gtmetrix.com

यहां छवि विवरण दर्ज करें



11
मुझे लगता है कि ज्यादातर ब्राउज़र केवल एक बार में 20 कनेक्शन बनाते हैं, इसलिए 20 के बाद पहला शुरू होने से पहले खत्म करना होता है, इसलिए 20 के बाद मंदी

1
मुझे लगता है कि आप अपने डोमेन के पहले उदाहरण को फिर से बनाना भूल गए। कम से कम आपको उनमें से बाकी मिल गए हैं: D
बनिएटेड

2
क्या आप उन चित्रों में से कुछ को प्रेत में नहीं मिला सकते हैं?
मार्सेल कोर्पेल

1
@Dagon, अवगत हो कि HTTP 1.1 RFCSHOULD , HTTP 1.1 क्लाइंट से HTTP 1.1 सर्वर पर अधिकांश 2 कनेक्शनों का उपयोग करने के लिए कहता है; HTTP 1.0 बेशक ज्यादा खुला है।
सरनाल्ड

1
@ वैगन ब्राउजर भी किसी भी डोमेन के लिए केवल 2 समवर्ती कनेक्शन बनाएगा।
एंडोफेगे

जवाबों:


61

सबसे पहले, उन कई डोमेन का उपयोग करके कई DNS लुकअप की आवश्यकता होती है। आप अनुरोधों को फैलाने के बजाय उन छवियों में से कई को स्प्राइट के संयोजन से बेहतर बना सकते हैं।

दूसरा, जब मैं आपका पृष्ठ लोड करता हूं, तो मुझे सभी .js. पर अधिकांश अवरुद्ध (~ 1.25) दिखाई देते हैं मैं देखता हूं कि jQuery के पुराने संस्करण के साथ शुरू होता है। आपको संदर्भ देना चाहिए कि Google CDN से, न केवल लोड समय कम करने के लिए , बल्कि संभावित रूप से इसके लिए एक HTTP अनुरोध से बचें

विशेष रूप से, सबसे वर्तमान jQuery और jQuery यूआई पुस्तकालयों को इन URL पर संदर्भित किया जा सकता है ( इस पोस्ट को देखें यदि आप रुचि रखते हैं कि मैंने क्यों छोड़ा है http:):

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

यदि आप डिफ़ॉल्ट jQuery यूआई विषयों में से एक का उपयोग कर रहे हैं, तो आप Google सीडीएन से इसके सीएसएस और चित्र भी खींच सकते हैं ।

JQuery होस्टिंग को अनुकूलित करने के साथ, आपको एक फ़ाइल में भी संयोजन awmlib2.jsऔर संयोजन करना चाहिए tooltiplib.js

यदि आप उन चीजों को संबोधित करते हैं, तो आपको एक महत्वपूर्ण सुधार देखना चाहिए।


1
बहुत बढ़िया टिप्पणी डेव! पुराना 1.3 JQuery बहुत छोटा था इसलिए मैंने सोचा कि इसके काम करते समय, यह तेज हो सकता है। लेकिन मुझे आपकी सिफारिशें पसंद हैं: Google CDN के कौन से लिंक आपको मेरे Jqyuery के रूप में उपयोग करने का सुझाव देते हैं? क्या मैं उसी तरह JQ UI जावास्क्रिप्ट का उपयोग कर सकता हूं? +1 बहुत बहुत धन्यवाद
सैम

2
मैं निश्चित रूप से jQuery के नवीनतम संस्करण (1.4.4 वर्तमान में) का उपयोग करने की सलाह देता हूं। जब छोटा और gzipped होता है, तो उनके बीच केवल कुछ बाइट्स अंतर होता है। मैंने Google CDN पर नवीनतम jQuery और jQuery UI संस्करणों के कुछ लिंक के साथ उत्तर को अपडेट किया है, जिसे मैं उपयोग करने की सलाह दूंगा।
डेव वार्ड

1
स्प्राइट के साथ अच्छा टिप, जो सर्वर को खुले कनेक्शन की संख्या को कम करना चाहिए
जेम्सहॉलस

वर्तमान में खुले कनेक्शन को कम करने पर काम कर रहा है (40 orso से अब 30 orso पर चला गया है ... अंतिम धक्का सबसे मुश्किल है क्योंकि कुछ छवियां पृष्ठभूमि को दोहरा रही हैं और स्प्राइट में नहीं जा सकती हैं (या ???)
सैम

अद्यतन पृष्ठ गति ग्रेड: (96%) YSlow ग्रेड: (90%) ... और अभी भी थंबनेल पहले जैसे ही धीमे हैं!
सैम

17

कुछ दिनों पहले मुझे भी इसी तरह की समस्या हुई थी और मैंने सिर पाया । जे.एस. यह एक जावास्क्रिप्ट प्लगिन है जो आपको सभी जेएस फाइल पार्सल लोड करने की अनुमति देता है। उम्मीद है की वो मदद करदे।


अतुल्य! मैं इसे कैसे अनदेखा कर सकता हूं? +1 इम अब इस एक का परीक्षण करने जा रहा है। एक फलफूल रात की तरह खुशबू आ रही है।
सैम

1
क्या मैं पूछ सकता हूं कि क्या आप schattenbaum.net से Schattenbaum हैं?
पेका

12

मैं एक विशेषज्ञ से बहुत दूर हूं लेकिन ...

इस संबंध में: "यदि कोई संशोधित-सशर्त अनुरोध पूर्ण सामग्री को अपरिवर्तित लौटाता है।" और मेरी टिप्पणियाँ

थंबनेल को जेनरेट करने के लिए इस्तेमाल किया जाने वाला कोड निम्नलिखित के लिए जाँचना चाहिए:

  1. क्या थंबनेल का कैश्ड संस्करण है।
  2. कैश्ड संस्करण मूल छवि से नया है।

यदि इनमें से कोई भी गलत हैं, तो थम्बनेल उत्पन्न किया जाना चाहिए और कोई फर्क नहीं पड़ता। यदि वे दोनों सत्य हैं तो निम्नलिखित जाँच की जानी चाहिए:

  1. क्या कोई HTTP_IF_MODIFIED_SINCE हेडर है
  2. कैश्ड संस्करण का अंतिम संशोधित समय HTTP_IF_MODIFIED_SINCE के समान है

यदि इनमें से कोई भी गलत है तो कैश्ड थंबनेल लौटाया जाना चाहिए।

यदि ये दोनों सत्य हैं तो 304 http स्थिति वापस की जानी चाहिए। मुझे यकीन नहीं है कि इसकी आवश्यकता है लेकिन मैं व्यक्तिगत रूप से 304 के साथ-साथ कैश-कंट्रोल, एक्सपायर और अंतिम-संशोधित हेडर भी लौटाता हूं।

GZipping के संबंध में, मुझे सूचित किया गया है कि GZip छवियों की कोई आवश्यकता नहीं है इसलिए मेरी टिप्पणी के उस भाग को अनदेखा करें।

संपादित करें: मैंने आपके पोस्ट के लिए अपने जोड़ को नोटिस नहीं किया।

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

मुझे यह भी पक्का पता है कि आपके कोड को HTTP_IF_MODIFIED_SINCE हेडर की जांच करनी होगी और उस पर प्रतिक्रिया देनी होगी। इन हेडर और आपकी .htaccess फ़ाइल को सेट करने से आवश्यक परिणाम नहीं मिलेगा।

मुझे लगता है कि आपको कुछ इस तरह की आवश्यकता है:

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

जेम्स आप अपने जवाब में अपने संपादन के बाद समस्या का सार! If Modified Sinceमुद्दा काम करने के लिए अब लगता है! फिर भी, छोटे अंगूठे के लिए लंबे हेडर / प्रतीक्षा समय अभी तक हल नहीं किया गया है ...
सैम

@James PS REdbot.org का कहना है कि आपका एक्सपायर हेडर गलत मूल्य है। मुझे लगता है कि यह जीएमटी होना चाहिए न कि सीईटी?
सैम

@ सॅम सॉरी मेरा सर्वर यूके में है इसलिए यह GMT डेट्स को अपने आप जेनरेट करता है। अगर तारीख के बजाय बस PHP फ़ंक्शन gmdate का उपयोग करें। यह आपके सर्वर समय के सापेक्ष जीएमटी तिथि का उत्पादन करना चाहिए।
जेम्स

1
@Sam, आपका प्रतीक्षा समय स्क्रिप्ट निष्पादन का समय है। इसका या तो आपके कोड के माध्यम से आपके हेडर को भेजने या आपके द्वारा आपके हेडर भेजे जाने के बाद बाहर न निकलने के बिंदु पर पहुंचने में लंबा समय लगता है।
जेम्स

@ जेम्स, मैं देख रहा हूँ ... लेकिन उस php थंबनेल जनरेटर के अलावा, अन्य समान रूप से लेन-लिपियों की एक पूरी बहुत कुछ है जो एक समय के एक अंश में सभी अन्य सामान (अनुवाद, मेनू लोडिंग आदि) करते हैं ... वे लगता है बिल्कुल भी अड़चन नहीं है ... क्या यह समस्या सीधे थंबनेल जनरेटर php तक ही है?
सैम

6

वाह, उस छवि का उपयोग करके चीजों को समझाना मुश्किल है .. लेकिन यहाँ, कुछ कोशिशें हैं:

  • 33-36 फ़ाइलों को देर से लोड किया जाता है, क्योंकि वे swf के भीतर गतिशील रूप से भरी हुई हैं, और किसी भी अतिरिक्त सामग्री को लोड करने से पहले swf (25) को पूरी तरह से लोड किया जाता है
  • फ़ाइलें 20 और 21 शायद हैं (मुझे नहीं पता, क्योंकि मुझे आपका कोड नहीं पता है) लाइब्रेरी जो सभी द्वारा लोड किए गए हैं। जेएस (11), लेकिन 11 को निष्पादित करने के लिए, यह पूरे पृष्ठ (और संपत्ति) की प्रतीक्षा करता है लोड करने के लिए (आपको इसे पहले से ही बदल देना चाहिए)
  • फ़ाइलें 22-32 उन दो पुस्तकालयों द्वारा भरी हुई हैं, फिर से पूरी तरह से लोड होने के बाद

दिलचस्प बिंदु। मुझे लगता है कि swf के आसपास कुछ भी नहीं है ... मैं कैसे पहले से ही बदल सकता हूं? मेरे पास एक कूबड़ है जिसका तुम मतलब है। इसके बारे में जब जावास्क्रिप्ट तैयार है और दस्तावेज़ पर यह या वह तैयार बताता है? क्या उस दस्तावेज़ को पहले से ही dom.ready द्वारा प्रतिस्थापित किया जाना चाहिए?
सैम

@Sam यदि आप क्लाइंट साइड कैशिंग (और आपको होना चाहिए) का उपयोग कर रहे हैं, तो आप swf द्वारा उपयोग किए गए संसाधनों को js या छिपे हुए divs में अपने पेज पर लोड कर सकते हैं ताकि जब swf उनसे अनुरोध करें कि वे पहले से ही क्लाइंट पर हैं।
एंडोफेज

4

बस एक सरल अनुमान है क्योंकि इस तरह के विश्लेषण के लिए बहुत अधिक ए / बी परीक्षण की आवश्यकता होती है: आपका .ch डोमेन पहुंचने में मुश्किल लगता है (पहले बाइट आने से पहले लंबे, हरे रंग की पट्टी)।

इसका मतलब यह होगा कि या तो .ch वेबसाइट खराब होस्ट की गई है या कि आपके पास आईएसपी उनके लिए एक अच्छा मार्ग नहीं है।

आरेखों को देखते हुए, यह एक बड़े प्रदर्शन हिट की व्याख्या कर सकता है।

एक साइड नोट पर, यह कूल टूल कुजिल है जो आपको रीसोर्स लोडिंग के ऑर्डर के आधार पर चीजों को छांटने में मदद कर सकता है।


4

अपनी साइट / पृष्ठ पर वाई-स्लो और पेज स्पीड टेस्ट चलाने का प्रयास करें, और संभावित प्रदर्शन बाधाओं को हल करने के लिए दिशानिर्देशों का पालन करें। वाई-स्लो या पेज स्पीड में एक बार उच्च स्कोर हासिल करने के बाद आपको भारी प्रदर्शन हासिल करना चाहिए।

ये परीक्षण आपको बताएंगे कि क्या गलत है और क्या बदलना है।


धन्यवाद! स्कोर हैं: पेज स्पीड पर 92 और यलो पर 93। गायब हैं: KEEP ALIVE = बंद और CDN का उपयोग नहीं करना।
सैम

अद्यतन: 96 और 90 क्रमशः वर्तमान में
सैम

4

तो आपकी PHP स्क्रिप्ट हर पेज लोड पर थंबनेल उत्पन्न कर रही है? सबसे पहले, अगर आपके द्वारा देखे जा रहे चित्र बार-बार नहीं बदल रहे हैं, तो क्या आप एक कैश सेट कर सकते हैं जैसे कि पृष्ठ लोड होने पर उन्हें हर बार पार्स न किया जाए? दूसरी बात, क्या आपकी PHP स्क्रिप्ट कुछ ऐसी चीज़ों का उपयोग कर रही है जो imagecopyresampled()थंबनेल बनाना चाहते हैं? यह एक गैर तुच्छ downsample है और PHP स्क्रिप्ट तब तक कुछ भी नहीं लौटाएगी जब तक कि इसकी सिकुड़ती हुई चीजें नीचे नहीं आती हैं। imagecopymerged()इसके बजाय का उपयोग करने से छवि की गुणवत्ता कम हो जाएगी, लेकिन इस प्रक्रिया को गति दें। और आप कितनी कमी कर रहे हैं? क्या ये थंबनेल 5% मूल छवि का आकार या 50% हैं? मूल छवि संभावना का एक बड़ा आकार मंदी की ओर अग्रसर है क्योंकि PHP स्क्रिप्ट को मूल छवि को मेमोरी में प्राप्त करने से पहले इसे छोटा करना और छोटा थंबनेल आउटपुट करना है।


धन्यवाद मिडनाइटलाइटिंग! एक कैश फ़ोल्डर है जहाँ थंबनेल JPGs बनाए जाते हैं और फिर से उपयोग किए जाते हैं, हालाँकि मुझे लगता है कि यहाँ जो स्क्रिप्ट मैंने खरीदी है उसकी समस्या है (और दूसरों के लिए ठीक काम करता है)
सैम

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

बेहतर अभी तक- अगर फ़ाइलें कैश की जाती हैं, तो HTML को इस तरह से उत्पन्न करें जो सीधे PHP से गुजरे बिना डिस्क से कैश की गई छवि में खींचती है। कि मैं अपनी स्क्रिप्ट्स में videodb.net के
andig

"कैशे फोल्डर है जहां ..." और कितनी जल्दी वे डिरेल हो गए हैं? क्या आपका URL सीधे कैश्ड फ़ाइल या PHP स्क्रिप्ट की ओर इशारा करता है? क्या आप रीडायरेक्ट () का पुनर्निर्देशन या उपयोग करते हैं? क्या एक ही PHP स्क्रिप्ट में थम्बनेल जेनरेशन कोड होता है - या क्या आप इसमें शामिल / इरक्वायर का उपयोग करके कोड के थोक को लोड करना स्थगित करते हैं?
सिम्बियन

4

मुझे आपकी वेबसाइट का URL मिल गया है और होमपेज से एक व्यक्तिगत jpg फ़ाइल की जाँच की। हालांकि लोडिंग समय उचित है (161ms), यह 126ms की प्रतीक्षा कर रहा है, जो कि बहुत अधिक है।

आपके अंतिम-संशोधित हेडर सभी पर सेट हो गए हैं, 01 जनवरी 2011 12:00:00 GMT, जो पीढ़ी की वास्तविक तारीख होने के लिए "गोल" दिखता है; ;-)

चूंकि कैश-कंट्रोल "सार्वजनिक, अधिकतम-आयु = 14515200" है, इसलिए मनमाने ढंग से अंतिम संशोधित हेडर 168 दिनों के बाद समस्या पैदा कर सकते हैं।

वैसे भी देरी का असली कारण यह नहीं है।

आपको यह देखना होगा कि जब थम्बनेल पहले से मौजूद है तो आपका थंबनेल जनरेटर क्या करता है और तस्वीर को चेक करने और डिलीवर करने में कितना समय लग सकता है।

आप स्क्रिप्ट को प्रोफाइल करने के लिए xdebug इंस्टॉल कर सकते हैं और देख सकते हैं कि अड़चनें कहां हैं।

हो सकता है कि पूरी चीज़ एक ढांचे का उपयोग करती है या कुछ के लिए कुछ डेटाबेस से जुड़ती है। मैंने कुछ सर्वरों पर बहुत धीमी गति से mysql_connect () देखा है, ज्यादातर क्योंकि वे टीसीपी का उपयोग कर कनेक्ट कर रहे थे और सॉकेट नहीं, कभी-कभी कुछ DNS मुद्दों के साथ।

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


सुराग कैप्सूल पर अपने जासूस और मौके के लिए धन्यवाद! पहली चीजें पहली: कोई डेटाबेस नहीं है। आपके निष्कर्ष मेरे जैसे ही हैं: इसका 90% समय इंतजार कर रहा है? पागल छोटे अंगूठे। अंतिम संशोधित हेडर पर दिलचस्प विचार, क्योंकि यहां जेम्स पोस्ट के अनुसार, मुझे उन अंतिम-संशोधित हेडर को STATIC (निश्चित) समय पर सेट करना था, न कि php gmdate जनरेटर द्वारा निर्धारित गतिशील / हमेशा बदलते समय। या शायद आप यहाँ कुछ और मतलब है? (इनाम के लिए नामांकित)
सैम

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

1
मैं शुद्ध स्थिर फाइलों पर अपेक्षाकृत लंबी देरी देख रहा हूं (उदाहरण के लिए अंगूठे से जुड़ी छवियां), जैसे 36ms। सर्वरों में से एक पर मैं प्रशासित कर रहा हूं (जो कि जानवर नहीं है ... RAL के 2Gb के साथ दोहरी कोर), मुझे लगभग आधा यह मिलता है, जैसे स्थैतिक फ़ाइलों पर 20ms।
कैप्सूल

दिलचस्प ... 1.what सॉफ्टवेयर / ऑनलाइन उपकरण क्या आप मापने के लिए उपयोग करते हैं? 2. क्या आपके तेज 20 एमएस माप अनुरूप हैं (कितने% xx%) आप अपने परिणामों को अलग-अलग पाते हैं? मेरे मामले में यह वास्तव में भिन्न होता है जो मैं परीक्षण उपकरण का उपयोग करता है पर निर्भर करता है। कुछ बहुत सुसंगत हैं ( gtmetrix.com ) कुछ वास्तव में अलग-अलग हैं ( p षड़यंत्र.कॉम ) और एक्सएक्स एमएस में समय देना मुश्किल है क्योंकि वे हर बार बदलते हैं ...
सैम

मैं Firebug की NET टैब का उपयोग कर रहा हूं। 20ms सबसे तेज समय है जो मुझे मिल रहा है। यह 20 और 28 के बीच भिन्न हो रहा है। निश्चित रूप से आपके सर्वर पर मैंने जिस 36ms को मापा था, वह सबसे तेज़ भी था।
कैप्सूल

4

यदि वास्तव में कोई अच्छा कारण नहीं है (आमतौर पर वहाँ नहीं है) आपकी छवियों को PHP दुभाषिया को आमंत्रित नहीं करना चाहिए।

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

यदि यह कम से कम काम नहीं करता है, तो अब आपके पास छवियों को बनाने और जांचने के तरीके से कोई लेना-देना नहीं है।


धन्यवाद गोरान, हालांकि यह वह सुरुचिपूर्ण समाधान नहीं है जिसकी मैं कामना करता हूं: मुझे लगता है कि मेरे मामले में कुछ गड़बड़ है, और आमतौर पर यह एक php स्क्रिप्ट के लिए लंबे समय तक नहीं लेता है, जो कि पता है कि एक 304 हेडर को पारित करने के लिए या सेंकना करने के लिए तार को जानने के लिए। छवि आदि अपने सुझाव के लिए वैसे भी धन्यवाद क्योंकि यह पूरी तरह से नए दृष्टिकोण से समस्या को निर्देशित करता है! जो अपने आप में मूल्यवान है +1
सैम

3

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

PHP हर स्क्रिप्ट को चलाने के लिए सत्र डेटा को लॉक करती है, जिस पल से सत्र हैंडलिंग शुरू होती है, उस पल तक स्क्रिप्ट समाप्त होती है, या जब session_write_close () कहा जाता है। यह प्रभावी रूप से चीजों को क्रमबद्ध करता है। सत्रों पर PHP पेज देखें, विशेष रूप से टिप्पणियां, जैसे यह एक


सुझाव के लिए धन्यवाद रिकार्डो! ऐसा लगता है कि एलिक्स आपके (सही?) के समान ही सुझाव दे रहा है। व्यावहारिक रूप में, आप मुझे कोड से डालने / हटाने के लिए क्या सुझाव देते हैं, फिर फिर से ग्राफ़ का परीक्षण करते हैं और फिर वापस रिपोर्ट करते हैं? बहुत सराहना की।
सैम

1
हां मुझे ऐसा लगता है। मेरा सुझाव है कि आप छवि बनाने वाली स्क्रिप्ट को बदल दें ताकि वे $ _SESSION डेटा या समान पर निर्भर न हों (हो सकता है कि वे पहले से ही न हों)। फिर जितना हो सके session_write_close () का उपयोग करें , या, और भी बेहतर, उन लिपियों पर सत्र का उपयोग करने से बचें। बाहर की जाँच करें php.net/manual/en/function.session-write-close.php
रिकार्डो

3

यह केवल एक जंगली अनुमान है क्योंकि मैंने आपके कोड को नहीं देखा है, लेकिन मुझे संदेह है कि सत्र यहां एक भूमिका निभा सकते हैं, निम्नलिखित PHP मैनुअल प्रविष्टि से है session_write_close():

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

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


आपके सुझाव के लिए धन्यवाद एलिक्स। एक प्रश्न: क्या exit();इसी तरह की लाइनों में कार्य है session_write_close();? वर्तमान में, कोड का मूल लेखक इस मुद्दे की जांच कर रहा है, लेकिन लगता है कि वह भी अंधेरे में एक सा है, क्योंकि कोड के उदार अद्यतन के साथ बेहतर इफ़-मॉडिफ़ाइड-चूंकि हैंडलिंग से वही देरी होती है (नया झरना रेखांकन समान रेखांकन उत्पन्न करता है, हालाँकि असली कृमि परिणाम दिखते हैं / तेज़ लोडिंग महसूस करते हैं! इसका एक बहुत ही अजीब मुद्दा ...
सैम

1
@ सलाम: मैं अभी आपको कोई भी स्रोत नहीं दे सकता, लेकिन मेरा मानना ​​है कि बाहर निकलने () पहले किसी भी विध्वंसक और / या फ़ंक्शंस को बंद करने के लिए पंजीकृत करता है और उसके बाद ही सत्र बंद होता है। किसी भी तरह, मैं शर्त लगाता हूं कि आपकी समस्या शायद आपके निकास () कॉल से पहले है। इन्हें भी देखें: stackoverflow.com/questions/1674314/…
एलिक्स एक्सल

2

क्या आपने यह देखने के लिए कि क्या कोई अंतर है, नियमित छवियों द्वारा php जनरेट किए गए थम्बनेल को बदलने की कोशिश की है? समस्या लगभग हो सकती है - आपके php कोड में एक बग जिसके कारण प्रत्येक सर्वर आह्वान पर थंबनेल का उत्थान हो रहा है - आपके कोड में देरी (नींद) एक घड़ी की समस्या से जुड़ी है - एक हार्डवेअर समस्या जो बहुत खराब दौड़ की स्थिति पैदा करती है? चूँकि सभी थंबनेल एक ही समय में लोड / जनरेट होते हैं।


कुछ ऐसा जो मैंने कुछ बिंदुओं पर सोचा था कि अपने विचारों को पढ़ने के लिए और पहले समाधान जो मैंने किया था, उसे पढ़ने के लिए एक +1 दे रहा था। मैं क्या कर रहा था, यह पता लगाने के लिए कि सामान्य छवियां भी धीरे-धीरे लोड होंगी, यह डाउनलोड बैंड स्पीड या शारीरिक रूप से सीमित कुछ हो सकता है, लेकिन मैंने पाया कि सामान्य स्थैतिक डंप चित्र (मैंने उत्पन्न अंगूठे को बचाया और स्थिर के रूप में अपलोड किया गया है) बहुत ज़्यादा तेज़। तो इसका क्या होगा थंबनेल जनरेटर php के साथ!
सैम

2

मुझे लगता है कि थंबनेल-जनरेटर स्क्रिप्ट का उपयोग करने के बजाय आपको TinySRC को तीव्र और क्लाउड-होस्टेड थंबनेल पीढ़ी के लिए प्रयास करना चाहिए । एपीआई का उपयोग करने के लिए यह एक बहुत ही सरल और आसान है, आप इसका उपयोग कर सकते हैं जैसे: -

http://i.tinysrc.mobi/ [ऊँचाई] / [चौड़ाई] /http://domain.tld/path_to_img.jpg

[चौड़ाई] (वैकल्पिक): - यह पिक्सल में एक चौड़ाई है (जो अनुकूली- या परिवार-आकार को ओवरराइड करता है)। यदि '-' या 'x' के साथ उपसर्ग किया जाता है, तो यह निर्धारित आकार के प्रतिशत तक घट जाएगा, या घट जाएगा।

[ऊँचाई] (वैकल्पिक): - यह पिक्सेल में एक ऊँचाई है, यदि चौड़ाई भी मौजूद है। यह अनुकूली- या परिवार-आकार को भी ओवरराइड करता है और इसे '-' या 'x' के साथ उपसर्ग किया जा सकता है।

आप यहां एपीआई सारांश की जांच कर सकते हैं


सामान्य प्रश्न

क्या LittleSrc मुझे खर्च करता है?

कुछ भी तो नहीं।

जब मैं smallSrc का उपयोग शुरू कर सकता हूं?

अभी।

सेवा कितनी विश्वसनीय है?

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

कितना तेज है?

स्मॉलसस्क कैश्स ने 24 घंटे तक मेमोरी और हमारे डेटास्टोर में छवियों का आकार बदला , और यह आपकी मूल छवि को हर बार नहीं लाएगा । यह सेवाओं को उपयोगकर्ता के दृष्टिकोण से तेज गति से तेज बनाता है। (और एक अच्छा साइड-इफेक्ट के रूप में आपके सर्वर लोड को कम करता है।)


शुभ लाभ। बस एक सुझाव, क्योंकि यू हमें कोड नहीं दिखा रहा है: पी


2

चूंकि कुछ ब्राउज़र प्रति डोमेन केवल 2 समानताएं डाउनलोड करते हैं, क्या आप अतिरिक्त डोमेन को दो से तीन अलग-अलग होस्टनाम में अनुरोधों को साझा करने के लिए नहीं जोड़ सकते । जैसे 1.imagecdn.com 2.imagecdn.com


आपके सुझाव के लिए +1: धन्यवाद, लेकिन अगर आप मेरे करीब दिखते हैं (स्वीकार किया गया: बहुत अराजक चित्र) तो आप देखेंगे कि कुछ आइटम ....... से आते हैं, तो कुछ ........ से आते हैं com .......... डी ब्यूट, शायद वह चाल भी नहीं करता जैसा कि आपके सुझाव से होता है? (मैं आपको केवल अलग-अलग डोमेन के बजाय उप-डोमेन का सुझाव देता हूं।)
सैम

1

सबसे पहले, आपको If-Modified-Sinceअनुरोधों को और ऐसे उचित तरीके से संभालने की जरूरत है , जैसा कि जेम्स ने कहा। उस त्रुटि में कहा गया है कि: "जब मैं आपके सर्वर से पूछता हूं कि क्या उस छवि को पिछली बार से संशोधित किया गया है, तो यह एक साधारण हां / नहीं के बजाय पूरी छवि भेजता है"।

कनेक्शन और पहली बाइट के बीच का समय आम तौर पर आपके PHP स्क्रिप्ट को चलाने का समय होता है। यह स्पष्ट है कि कुछ ऐसा हो रहा है जब वह स्क्रिप्ट चलने लगती है।

  1. क्या आपने इसे प्रोफाइलिंग माना है? इसके कुछ मुद्दे हो सकते हैं।
  2. उपरोक्त मुद्दे के साथ संयुक्त, आपकी स्क्रिप्ट आवश्यकता से कई गुना अधिक चल सकती है। आदर्श रूप से, यह केवल अंगूठे को उत्पन्न करना चाहिए यदि मूल छवि को संशोधित किया जाए और हर दूसरे अनुरोध के लिए कैश्ड अंगूठे भेजें। क्या आपने जाँच किया है कि स्क्रिप्ट छवियों को अनावश्यक रूप से उत्पन्न कर रही है (जैसे प्रत्येक अनुरोध के लिए)?

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

इनके अलावा, आप इस समग्र अच्छा SO प्रश्न के प्रदर्शन भागों से कुछ उज्ज्वल अनुकूलन विचारों को लागू कर सकते हैं कि कैसे वेबसाइटों को सही तरीके से किया जाए , जैसे कि आपके संसाधनों को कुकरहित उप-डोमेन में विभाजित करना, आदि। लेकिन किसी भी दर पर, एक 3k छवि लोड करने के लिए दूसरा नहीं लेना चाहिए, यह तब स्पष्ट होता है जब ग्राफ़ में अन्य वस्तुओं की तुलना में। आपको अनुकूलन करने से पहले समस्या को हल करने का प्रयास करना चाहिए।


-1: 'संशोधित नहीं' और बिना संशोधित समय समाप्ति के सशर्त अनुरोध का जवाब देने से आपकी साइट 99.9% मामलों में धीमी हो जाएगी (BTW, AFAIK, 304 जवाब के साथ संशोधित कैशिंग जानकारी जारी करने के लिए अपाचे प्राप्त करने का कोई तरीका नहीं है)
सिम्बियन

और, मेरे जवाब के साथ क्या करना है?
हालिल Halzgür

1

क्या आपने विशेष रूप से छवियों और स्टाइलशीट जैसे स्थैतिक डेटा की सेवा के लिए NGINX वेबसर्वर के तहत कई उप डोमेन स्थापित करने की कोशिश की है ? इस विषय में पहले से ही कुछ मददगार पाया जा सकता है ।


धन्यवाद! हालांकि, कुछ शोधों के बाद, ऐसा लगता है, कि उप-स्थिरियों को सर्वर स्टैटिक कुकीज में सेट करना केवल एक साइट को तेज़ बनाता है, जब कई चित्र होते हैं, थोड़े अतिरिक्त ओवरहेड की कीमत पर। मेरे मामले में मैं शर्त लगाता हूं कि 6 छवियां उप / अतिरिक्त डोमेन के ओवरहेड की तुलना में तेज़ी से लोड नहीं होंगी। सही?
सैम

1
NGinx Sendfile syscall का समर्थन करता है, जो सीधे hdd से फाइल भेज सकता है। कृपया निम्नलिखित डॉक wiki.nginx.org/HttpCoreModule पर निर्देशों को ' sendfile ', 'aio' पर देखें। यह वेबसर्वर अपाचे की तुलना में बहुत तेजी से छवियों की तरह स्थिर फ़ाइलों को कार्य करता है।
nefo_x

दिलचस्प ... मुझे नहीं पता था कि अपाचे से बेहतर कुछ भी हो सकता है। वैसे, आपका क्या मतलब है straight from hdd। क्या आपको इसके बजाय मतलब है straight from DDR3 RAM/ straight from Solid State Diskमुझे पता है कि डीडीआर 3 राम या सॉलिड स्टेट डिस्क के विपरीत हार्डडिस्क का उपयोग बहुत धीमा है। लेकिन मुझे लगता है कि यह यहाँ अड़चन नहीं है ...
सैम

1
बिंदु यह है कि अपाचे करता है के रूप में nginx स्थिर डेटा आउटपुट को बफर नहीं करता है।
nefo_x

1

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

पटकथा को संभालने वाली स्क्रिप्ट को किसी प्रकार के कैशिंग का उपयोग करने की उम्मीद करनी चाहिए ताकि आपके द्वारा सेवा की जा रही छवियों पर जो भी कार्रवाई हो वह केवल पूरी तरह से आवश्यक हो। ऐसा लगता है कि हर बार जब आप थंबनेल परोसते हैं तो कुछ महंगा ऑपरेशन होता है जो स्क्रिप्ट से किसी भी आउटपुट (हेडर सहित) में देरी कर रहा है ।


+1 रोमांचक अनुमान अब इसे आज़माएं! रिपोर्ट करेंगे जब मुझे नया झरना बहता मिला ...
सैम

दुर्भाग्य से, flush();हेडर के बाद सही जोड़ने के बाद, लगता है कि कोई बदलाव नहीं हुआ है! इसका क्या मतलब हो सकता है?
सैम

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

क्या सीएसएस या <img> टैग में संदर्भित किए जा रहे हैं?
AR Younce

Css में संदर्भित से आपका क्या अभिप्राय है? वे शरीर HTML के पक्ष में हैं और निम्नानुसार हैं: <img src="thumbprocessor.php?src=/folder/image.jpg&w=100&h=200" id="thumbnail"/>
सैम

1

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

TTFB बैकेंड स्टफ, सर्वर स्टफ, प्री-प्रोसेसिंग से पहले आउटपुट और हैंडशेकिंग है।

धीमी गति से डेटाबेस प्रश्न, धीमी गति से कार्य करने के लिए धीमी गति से सामान खोजने के लिए अपने कोड निष्पादन, समय दर्ज करने और कार्य / विधियों से बाहर निकलने का समय। यदि आप php का उपयोग करते हैं, तो Firephp आज़माएँ । कभी-कभी यह स्टार्टअप के दौरान चलाए जा रहे एक या दो धीमी पूछताछ या सत्र की जानकारी खींचने या प्रमाणीकरण की जाँच करने और आरंभिक जांच जैसे कि क्या नहीं है। प्रश्नों का अनुकूलन करने से कुछ अच्छे लाभ प्राप्त हो सकते हैं। कभी-कभी php prepend या spl autoload का उपयोग करके कोड चलाया जाता है ताकि वे सब कुछ पर चलें। अन्य समय में यह कॉन्फ़िगर किया गया अपाचे कॉन्फिग और ट्वीकिंग हो सकता है जो दिन बचाता है।

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

आप कई डोमेन और संसाधनों का मुकाबला करने के लिए DNS प्रीफ़ेटिंग की कोशिश कर सकते हैं, http://html5boilerplate.com/docs/DNS-Pref/che/

क्या सर्वर आपका एक अच्छा / सभ्य सर्वर है? कभी-कभी एक बेहतर सर्वर बहुत सारी समस्याओं को हल कर सकता है। मैं ' हार्डवेयर सस्ता है, प्रोग्रामर महंगे हैं ' मानसिकता का प्रशंसक हूं , अगर आपके पास मौका है और पैसा एक सर्वर को अपग्रेड करता है। और / या एक CDN जैसे कि maxcdn या cloudflare या समान का उपयोग करें।

शुभ लाभ!

(पीएस मैं इनमें से किसी भी कंपनी के लिए काम नहीं करता हूं। इसके अलावा ऊपर दिए गए क्लाउडफ्लेअर लिंक का तर्क होगा कि टीटीएफबी इतना महत्वपूर्ण नहीं है, मैंने इसे फेंक दिया ताकि आप एक और ले सकें।)


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

-1

कहने के लिए क्षमा करें, आप कुछ डेटा प्रदान करते हैं। और आपके पास पहले से ही कुछ अच्छे सुझाव थे।

आप उन चित्रों की सेवा कैसे कर रहे हैं? यदि आप PHP के माध्यम से उन स्ट्रीमिंग कर रहे हैं, तो आप बहुत बुरा काम कर रहे हैं, भले ही वे पहले से ही उत्पन्न हो।

PHP के साथ कभी भी इमेजेज नहीं। यह आपके सर्वर को धीमा कर देगा, इससे कोई फर्क नहीं पड़ता कि आप इसका उपयोग करते हैं।

उन्हें एक उपयोगी फ़ोल्डर में रखो, एक सार्थक यूआरआई के साथ। फिर उन्हें सीधे उनके वास्तविक यूआरआई के साथ कॉल करें। यदि आपको फ्लाई जेनरेशन की आवश्यकता है तो आपको इमेज डायरेक्टरी में एक .htaccess को डालना चाहिए जो कि जनरेटर php-script पर रीडायरेक्ट करता है केवल अगर अनुरोध छवि गायब है। (इसे कैश-ऑन-रिक्वेस्ट रणनीति कहा जाता है)।

ऐसा करने से php सेशन, ब्राउज़र-प्रॉक्सी, कैशिंग, ETAGS, जो भी एक बार में ठीक हो जाएगा।

यदि ठीक से कॉन्फ़िगर किया गया है तो WP-Supercache इस रणनीति का उपयोग करता है।

मैंने इसे कुछ समय पहले लिखा था ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), अंतिम संशोधन टूट गए हैं, लेकिन मुझे लगता है कि 8 या उससे कम काम करना चाहिए और आप कर सकते हैं केवल चीजों को परखने के लिए एक उदाहरण के रूप में .htaccess को पकड़ो (हालाँकि मेरे द्वारा उपयोग किए गए तरीके से .htaccess को कॉन्फ़िगर करने के बेहतर तरीके हैं)।

मैंने इस ब्लॉग पोस्ट में उस रणनीति का वर्णन किया है ( http://www.stefanoforenza.com/need-for-cache/ )। यह शायद बुरी तरह से लिखा गया है, लेकिन यह चीजों को स्पष्ट करने में मदद कर सकता है।

आगे पढ़े: http://meta.wikimedia.org/wiki/404_handler_caching


मन, ErrorDocument वास्तव में सबसे अच्छी चीज नहीं है जो आप कर सकते हैं, क्योंकि यह अपाचे की त्रुटि लॉग में प्रविष्टियां उत्पन्न करता है, एक -f पुनर्निर्देशन बेहतर होगा।
टैकोन

आपके इनपुट tacone के लिए धन्यवाद। क्या आप यह कह रहे हैं कि php स्क्रिप्ट कितनी भी अच्छी क्यों न हो, यह सर्वर को धीमा कर देगी, या जैसा कि आपने अपनी पोस्ट में कहा था "यह आपके सर्वर को मार देगा, चाहे कुछ भी हो।"
सैम

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

मतदाताओं को बताएं, क्या आप बता सकते हैं कि क्यों?
tacone
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.