Önbelleğe alınmış, PHP tarafından oluşturulan Küçük Resimler yavaş yükleniyor

Soru Bölüm A ▉ (100 ödül, ödüllü)
Ana soru, bu sitenin nasıl daha hızlı yükleneceği idi. Önce bu şelaleleri okumamız gerekiyordu. Şelale okuma analizi hakkındaki önerileriniz için teşekkür ederiz. Burada gösterilen çeşitli şelale grafiklerinden belli olan ana darboğaz: PHP tarafından oluşturulan küçük resimler. David'in önerdiği CDN'den protokol içermeyen jquery yüklemesi, sitemi genel olarak sadece% 3 daha hızlı hale getirse de, sitenin ana darboğazına cevap vermese de ödülümü aldı. Sorumun açıklığa kavuşturulması için zaman ve başka bir ödül:

Soru Bölüm B 100 (100 ödül, ödüllü)
Yeni odak noktası, yükleme gecikmesinin çoğuna neden olan 6 jpg görüntüsünün sahip olduğu sorunu çözmekti. Bu 6 görüntü, PHP tarafından oluşturulan küçük resimlerdir, küçük ve sadece 3 ~ 5 kb'dir, ancak nispeten çok yavaş yüklenir . Çeşitli grafiklerde " ilk bayt zamanı " na dikkat edin . Sorun çözülmeden kaldı, ancak bir ödül, RedBot'un altı çizdiği başlık hatasını düzelten James'e gitti : "If-Modified-Since koşullu isteği tüm içeriği değiştirmedi." .

Soru Bölüm C ▉ (son ödül: 250 puan)
Ne yazık ki, REdbot.org üstbilgi hatası bile giderildikten sonra, PHP tarafından oluşturulan görüntülerin neden olduğu gecikme dokunulmadan kaldı. Bu minik cılız 3 ~ 5Kb küçük resimler ne düşünüyor? Tüm bu başlık bilgileri aya ve arkaya bir roket gönderebilir. Bu darboğazla ilgili herhangi bir öneri çok takdir ediliyor ve zaten yedi aydır bu darboğaz problemine takılı kaldığım için olası cevap olarak değerlendiriliyor. Şimdiden teşekkürler.

[Sitemdeki bazı arka plan bilgileri: CSS en üstte. Alttaki JS (Jquery, JQuery UI, satın alınmış menü awm / menu.js motorları, sekmeler js motoru, video swfobject.js) İkinci resimdeki siyah çizgiler neyin yükleneceğini başlatır. Kızgın robot benim evcil hayvanım "ZAM". Zararsız ve çoğu zaman daha mutlu.]

Yük Şelalesi: Kronolojik | http://webpagetest.org

Gruplandırılmış Paralel Etki Alanları | http://webpagetest.org

Site-Perf Şelalesi | http://site-perf.com

Pingdom Araçları Şelale | http://tools.pingdom.com

GTmetrix Şelalesi | http://gtmetrix.com

İlk olarak, bu birden çok alan adını kullanmak için birkaç DNS araması gerekir. Bu görüntülerin çoğunu istekleri yaymak yerine bir hareketli grafiğe birleştirmek daha iyi olur .

İkinci olarak, sayfanızı yüklediğimde, engellemenin çoğunu (~ 1.25s) all.js'de görüyorum. Görüyorum ki (eski bir sürümü) jQuery ile başlar. Google CDN'den yalnızca yükleme süresini azaltmak için değil , aynı zamanda bunun için bir HTTP isteğinden tamamen kaçınmasını da belirtmelisiniz .

Özellikle, en güncel jQuery ve jQuery UI kütüphaneleri aşağıdaki URL'ler aracılığıyla başvurulabilir (bkz bu yazıyı sana ilgi ihmal sizsiniz, neden ise 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

Varsayılan jQuery kullanıcı arayüzü temalarından birini kullanıyorsanız , CSS'sini ve resimlerini Google CDN'sinden de çekebilirsiniz .

JQuery optimize barındırma ile, aynı zamanda birleştirmek gerektiğini awmlib2.jsve tooltiplib.jstek bir dosyada.

Bunlara hitap ederseniz, önemli bir gelişme görmelisiniz.

Birkaç gün önce benzer bir sorun yaşadım ve head.js'yi buldum . Tüm JS dosyalarını paralell yüklemenizi sağlayan bir Javascript Eklentisidir. Umarım yardımcı olur.

Ben bir uzman olmaktan uzak ama ...

Bununla ilgili olarak: "Bir If-Modified-Since koşullu isteği tüm içeriği değiştirmedi." ve yorumlarım.

Küçük Resimleri oluşturmak için kullanılan kod aşağıdakileri kontrol etmelidir:

1. Küçük resmin önbelleğe alınmış bir sürümü var mı?
2. Önbelleğe alınan sürüm orijinal resimden daha yeni.

Bunlardan herhangi biri yanlışsa, küçük resim oluşturulmalı ve ne olursa olsun döndürülmelidir. Her ikisi de doğruysa aşağıdaki kontrol yapılmalıdır:

1. Bir HTTP_IF_MODIFIED_SINCE başlığı var mı
2. Önbelleğe alınan sürümün son değiştirilme zamanı HTTP_IF_MODIFIED_SINCE ile aynı mı?

Bunlardan herhangi biri yanlışsa, önbelleğe alınan küçük resim döndürülmelidir.

Bunların her ikisi de doğruysa, 304 http durumu döndürülmelidir. Gerekli olup olmadığından emin değilim ama 304 ile birlikte şahsen Cache-Control, Expires ve Last-Modified headers'ı da iade ediyorum.

GZipping ile ilgili olarak, GZip görüntülerine gerek olmadığı konusunda bilgilendirildim, bu yüzden yorumumun bu bölümünü göz ardı edin.

Düzenleme: Yayınınıza eklediğinizi fark etmedim.

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");

Kodunuzun HTTP_IF_MODIFIED_SINCE üstbilgisini kontrol etmesi ve buna tepki vermesi gerektiğinden de eminim. Sadece bu başlıkları ve .htaccess dosyanızı ayarlamak gerekli sonucu vermeyecektir.

Bence böyle bir şeye ihtiyacın var:

$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

Vay canına, bu görüntüyü kullanarak olayları açıklamak zor .. Ama burada, bazı denemeler:

• dosyaları 33-36 bu geç yükler, çünkü swf içine dinamik olarak yüklenirler ve swf (25) herhangi bir ek içerik yüklemeden önce tamamen yüklenir
• 20 ve 21 dosyaları belki (bilmiyorum, çünkü kodunuzu bilmiyorum) all.js (11) tarafından yüklenen kütüphanelerdir, ancak 11'in çalıştırılması için tüm sayfayı (ve varlıkları) bekler yüklemek için (bunu şimdiden değiştirmelisiniz)
• 22-32 dosyaları bu iki kütüphane tarafından yüklenir, yine bunlar tamamen yüklendikten sonra

Basit bir tahmin, çünkü bu tür bir analiz çok fazla A / B testi gerektirir: .ch alan adınıza ulaşmak zor görünüyor (ilk bayt gelmeden önce uzun, yeşil bantlar).

Bu, ya .ch web sitesinin kötü barındırıldığı veya ISS'nizin onlara iyi bir yolu olmadığı anlamına gelir.

Diyagramlar göz önüne alındığında, bu büyük bir performans isabeti açıklayabilir.

Bir yan notta, kaynak yükleme siparişinize bağlı olarak işleri sıralamanıza yardımcı olabilecek bu harika araç cuzillion var.

Sitenizde / sayfanızda Y! Yavaş ve Sayfa Hızı testleri yapmayı deneyin ve olası performans darboğazlarını sıralamak için yönergeleri izleyin. Y! Yavaş veya Sayfa Hızı değerlerinde daha yüksek puanlar elde ettikten sonra büyük performans kazançları elde etmelisiniz.

Bu testler size neyin yanlış olduğunu ve neyin değişeceğini söyleyecektir.

PHP betiğiniz her sayfa yükünde küçük resimler oluşturuyor mu? Öncelikle, küçük resim görüntüleri bu kadar sık ​​değişmiyorsa, sayfa her yüklendiğinde ayrıştırılmaları gerekmeyecek bir önbellek ayarlayabilir misiniz? İkincisi, PHP betiğiniz imagecopyresampled()küçük resimler oluşturmak gibi bir şey kullanıyor mu? Bu önemsiz bir alt örnek ve PHP betiği, işleri küçülene kadar hiçbir şey döndürmez. Kullanılması imagecopymerged()görüntünün kalitesini düşürebilir, fakat sürecini hızlandırır yerine. Ve ne kadar indirim yapıyorsunuz? Bu küçük resimler orijinal resmin boyutunun% 5'i mi,% 50'si mi? PHP görüntüsünün küçültülmesi ve daha küçük bir küçük resim çıkarmadan önce orijinal görüntüyü belleğe alması gerektiğinden, orijinal görüntünün daha büyük bir boyutu muhtemelen yavaşlamaya yol açar.

Web sitenizin URL'sini buldum ve ana sayfadan ayrı bir jpg dosyası kontrol ettim. Yükleme süresi şimdi makul olsa da (161ms), çok fazla olan 126ms'yi bekliyor.

Son değiştirilen başlıklarınızın tümü Cts, 01 Oca 2011 12:00:00 GMT olarak ayarlanmıştır. Bu, GMT'nin gerçek üretim tarihi olmak için çok "yuvarlak" görünüyor ;-)

Önbellek kontrolü "herkese açık, maks. Yaş = 14515200" olduğundan, en son değiştirilen keyfi başlıklar 168 gün sonra soruna neden olabilir.

Her neyse, bu gecikmelerin gerçek nedeni değil.

Küçük resim oluşturucunuzda küçük resim oluşturucunun ne yaptığını ve resmi kontrol etmek ve teslim etmek için ne kadar zaman harcayabileceğini kontrol etmeniz gerekir.

Komut dosyasını profillemek ve darboğazların nerede olduğunu görmek için xdebug yükleyebilirsiniz .

Belki de her şey bir çerçeve kullanır veya hiçbir şey için bazı veritabanına bağlanır. Bazı sunucularda çok yavaş mysql_connect () gördüm, çoğunlukla TCP kullanarak soket değil, bazen de bazı DNS sorunları ile bağlandıkları için.

Ücretli jeneratörünüzü buraya gönderemeyeceğinizi anlıyorum ama çok fazla olası sorundan korkuyorum ...

Gerçekten iyi bir neden yoksa (genellikle yoktur) resimleriniz PHP yorumlayıcısını çağırmamalıdır.

Dosya sunucusunda bulunuyorsa, görüntüyü doğrudan sunucu yapan web sunucunuz için bir yeniden yazma kuralı oluşturun. Değilse, resmi oluşturmak için PHP betiğinize yönlendirin. Görüntüyü düzenlediğinizde, önbelleğe alınmış sürümü olan kullanıcıları yeni düzenlenmiş görüntüyü almaya zorlamak için görüntülerin dosya adını değiştirin.

En azından işe yaramazsa, artık görüntülerin oluşturulma ve kontrol edilme şekliyle ilgisi yoktur.

PHP'nin oturum verilerini kullanımını araştırın. Belki (sadece belki), görüntü üreten PHP betiği, hala işleyen ana sayfa veya diğer görüntü oluşturma komut dosyaları tarafından kilitlenen oturum verilerinde bir kilit almayı bekliyor. Bu, tarayıcının sunucuyu beklemesi nedeniyle tüm JavaScript / tarayıcı optimizasyonlarını neredeyse alakasız hale getirir.

PHP, çalışan her komut dosyası için oturum verilerini, oturum işlemenin başladığı andan komut dosyasının bittiği ana kadar veya session_write_close () çağrıldığında kilitler. Bu etkili bir şekilde serileştirir. Gibi, seans özellikle yorumlarınızı PHP sayfasına bakın bu bir .

Bu sadece vahşi bir tahmin çünkü ben kod bakmadım ama oturumları burada bir rol oynuyor olabilir şüpheli, aşağıdaki PHP Manuel girişinden session_write_close():

Oturum verileri genellikle script'iniz session_write_close () öğesini çağırmaya gerek kalmadan sonlandırıldıktan sonra depolanır, ancak eşzamanlı yazma işlemlerini önlemek için oturum verileri kilitlendiğinden, oturumda herhangi bir zamanda yalnızca bir komut dosyası çalışabilir. Çerçeve kümelerini oturumlarla birlikte kullanırken, bu kilitleme nedeniyle çerçevelerin tek tek yüklenmesini deneyimleyeceksiniz. Oturum değişkenlerinde tüm değişiklikler yapılır yapılmaz oturumu sonlandırarak tüm çerçeveleri yüklemek için gereken süreyi azaltabilirsiniz.

Dediğim gibi, kodunuzun ne yaptığını bilmiyorum ama bu grafikler garip bir şekilde şüpheli görünüyor. Çok parçalı bir dosya sunma işlevini kodladığımda benzer bir sorun yaşadım ve aynı sorunu yaşadım. Büyük bir dosya sunarken, çok parçalı işlevselliği çalıştıramadım veya indirme tamamlanana kadar başka bir sayfa açamadım. Aramaksession_write_close() hem sorunlarımı düzeltti .

Herhangi bir fark olup olmadığını görmek için php oluşturulan thumnails düzenli görüntülerle değiştirmeyi denediniz mi? Sorun etrafında olabilir - php kodunuzda bir hata her sunucu çağırma üzerine küçük bir rejenerasyon yol - bir saat sorunu ile ilişkili kodunuzda (uyku ()?) Bir gecikme - çok kötü bir yarış durumu neden bir hardrive sorunu çünkü tüm küçük resimler aynı anda yüklenir / oluşturulur.

Bence kullanmak yerine küçük resim jeneratör komut size vermelidir TinySRC hızlı perhizden ve bulut barındırılan nesil küçük resim için bir deneyin. Çok basit ve kullanımı kolay bir API'ye sahiptir, aşağıdaki gibi kullanabilirsiniz: -

http://i.tinysrc.mobi/ [yükseklik] / [genişlik] /http://domain.tld/path_to_img.jpg

[genişlik] (isteğe bağlı): - Bu, piksel cinsinden bir genişliktir (uyarlanabilir veya aile boyutlandırmasını geçersiz kılar). '-' veya 'x' ile ön ek getirilirse, belirlenen boyuttan çıkarılır veya yüzde olarak küçülür.

[height] (isteğe bağlı): - Genişlik de varsa piksel cinsinden bir yüksekliktir. Ayrıca, uyarlanabilir veya aile boyutlandırmasını geçersiz kılar ve '-' veya 'x' ile ön ek yapılabilir.

API özetini buradan kontrol edebilirsiniz

SSS

TinySrc'in bana maliyeti nedir?

Hiçbir şey değil.

TinySrc kullanmaya ne zaman başlayabilirim?

Şimdi.

Hizmet ne kadar güvenilir?

TinySrc servisi hakkında hiçbir garanti vermiyoruz. Bununla birlikte, büyük, dağıtılmış bir bulut altyapısı üzerinde çalışır , bu nedenle dünya çapında yüksek kullanılabilirlik sağlar. Tüm ihtiyaçlarınız için yeterli olmalıdır.

Ne kadar hızlı?

tinySrc, yeniden boyutlandırılmış görüntüleri bellekte ve veri mağazamızda 24 saate kadar önbelleğe alır ve her seferinde orijinal görüntünüzü getirmez . Bu, hizmetleri inanılmaz derecede hızlı hale getirir kullanıcının bakış açısından . (Ve sunucu yükünüzü güzel bir yan etki olarak azaltır.)

İyi şanslar. Sadece bir öneri, çünkü bize kodu göstermediğinden: p

Bazı tarayıcılar alan başına yalnızca 2 paralel indirme indirdiğinden, iki ila üç farklı ana bilgisayar adından gelen istekleri parçalamak için ek alan adları ekleyemezdiniz . ör. 1.imagecdn.com 2.imagecdn.com

Her şeyden önce, If-Modified-SinceJames'in dediği gibi istekleri ve böyle uygun bir şekilde işlem yapmalısınız . Bu hata şunu belirtir: "Sunucunuza bu görüntünün son kez değiştirilip değiştirilmediğini sorduğumda, basit bir evet / hayır yerine tüm görüntüyü gönderir".

Bağlantı ve ilk bayt arasındaki zaman genellikle PHP betiğinizin çalıştığı zamandır. Bu komut dosyası çalışmaya başladığında bir şeyler oluyor gibi görünüyor.

1. Profil oluşturmayı düşündünüz mü? Bazı sorunları olabilir.
2. Yukarıdaki sorunla birlikte, komut dosyanız gerektiğinden çok daha fazla çalışıyor olabilir. İdeal olarak, yalnızca orijinal görüntü değiştirilirse başparmak üretmeli ve diğer tüm istekler için önbelleğe alınmış başparmak göndermelidir. Betiğin görüntüleri gereksiz şekilde oluşturup oluşturmadığını kontrol ettiniz mi (örn. Her istek için)?

Uygulama aracılığıyla uygun başlıklar oluşturmak biraz zor, ayrıca sunucu tarafından üzerine yazılabilir. Önbelleksiz istek üstbilgileri gönderen herkes küçük resim oluşturucunuzun sürekli çalışmasına (ve yükleri yükseltmesine) neden olacağı için kötüye kullanıma maruz kalırsınız. Bu nedenle, mümkünse, oluşturulan bu baş parmakları kaydetmeyi deneyin, kaydedilen görüntüleri doğrudan sayfalarınızdan arayın ve başlıkları yönetin .htaccess. Bu durumda, .htaccesssunucunuz doğru bir şekilde yapılandırılmışsa, hiçbir şey yapmanız gerekmez .

Bunların dışında size bu genel olarak güzel SO sorunun performans kısımlarından parlak optimizasyon bazı fikirleri uygulayabilirsiniz web sitelerine doğru yolu nasıl vb çerezsiz alt alanlara, bölünerek gibi, kaynaklarınızı Ama her halükarda bir 3k görüntü yüklemesi bir saniye sürmemelidir, bu grafikteki diğer öğelerle karşılaştırıldığında açıktır. Optimizasyondan önce sorunu tespit etmeye çalışmalısınız.

NGINX web sunucusu altında, özellikle görüntü ve stil sayfaları gibi statik verileri sunmak için birkaç alt alan adı ayarlamayı denediniz mi? Bu konuda zaten yararlı bir şey bulunabilir .

Geciken küçük resimlerle ilgili olarak, küçük resim oluşturma komut dosyanızdaki son header () çağrısından hemen sonra bir flush () çağrısı yapmayı deneyin . İşiniz bittiğinde, şelale grafiğinizi yeniden oluşturun ve gecikmenin artık başlıklar yerine gövde üzerinde olup olmadığını görün. Eğer öyleyse, görüntü verilerini üreten ve / veya çıktı veren mantığa uzun bir göz atmanız gerekir.

Küçük resimleri işleyen komut dosyası, sunmakta olduğunuz resimler üzerinde ne yaparsa yapsın yalnızca kesinlikle gerekli olduğunda gerçekleşmesi için bir tür önbellek kullanmasını umar. Küçük resimlere her yazdığınızda , komut dosyasından herhangi bir çıktıyı (başlıklar dahil) geciktiren bazı pahalı işlemler gerçekleşiyor gibi görünüyor .

Yavaş sorunun çoğu TTFB (İlk bayt zamanı) çok yüksek. Bu sunucu yapılandırma dosyaları, kod ve altta yatan donanım ile samimi olmadan mücadele etmek zor, ama her istek üzerine yaygın olduğunu görebilirsiniz. Çok fazla yeşil çubuk (kötü) ve çok az mavi çubuk (iyi) var. Bu alanda çok şey yaptığınıza inandığım için ön ucu biraz optimize etmeyi bırakmak isteyebilirsiniz. " Son kullanıcı yanıt süresinin% 80-% 90'ı ön uçta geçiyor " atasözüne rağmen, sizinkinin arka uçta gerçekleştiğine inanıyorum.

TTFB arka uç, sunucu, çıktı ve el sıkışma öncesi ön .

Yavaş veritabanı sorguları, zamana girme ve işlevlerden çıkma gibi yavaş şeyler bulmak için kod yürütmenizi zamanlayın. Eğer php kullanıyorsanız, Firephp'i deneyin . Bazen başlatma veya başlatma sırasında oturum bilgilerini almak veya kimlik doğrulamasını kontrol etmek gibi bir veya iki yavaş sorgu çalıştırılır. Sorguları optimize etmek bazı iyi kazançlar sağlayabilir. Bazen kod php prepend veya spl autoload kullanılarak çalıştırılır, böylece her şey üzerinde çalışırlar. Diğer zamanlarda güne tasarruf sağlayan apache conf ve tweaking mal yapılandırılmış olabilir.

Verimsiz döngüler arayın. Önbelleklerin yavaş getirilmesini veya hatalı disk sürücülerinin veya yüksek disk alanı kullanımının neden olduğu yavaş g / Ç işlemlerini arayın. Bellek kullanımlarını ve ne kullanıldığını ve nerede kullanıldığını arayın. Aynı konumda değil, dünyanın farklı yerlerinden yalnızca ilk görünümü kullanarak tek bir görüntü veya dosya üzerinde 10 çalışmanın web sayfası testini tekrarlayın. Ve erişim ve hata günlüklerinizi okuyun, çok fazla geliştirici bunları görmezden gelir ve sadece çıkan ekran hatalarına güvenir. Web barındırıcınızın desteği varsa, yardım isteyin, belki kibarca yine de yardım isteyin, zarar vermez.

Birçok alan ve kaynakla mücadele etmek için DNS Önceden Getirmeyi deneyebilirsiniz, Http://html5boilerplate.com/docs/DNS-Prefetching/ adresindeki

Sunucu kendi iyi / iyi bir sunucu mu? Bazen daha iyi bir sunucu birçok sorunu çözebilir. Ben bir hayranıyım şans ve para bir sunucu yükseltme varsa donanım ucuz, programcılar pahalı ' zihninin . Ve / Veya maxcdn veya cloudflare veya benzeri bir CDN kullanın .

İyi şanslar!

(ps ben bu şirketlerin herhangi biri için çalışmıyor. Ayrıca yukarıdaki cloudflare bağlantı TTFB o kadar önemli olmadığını iddia edecek, ben başka bir almak böylece orada attı.)

Üzgünüm, çok az veri sağlıyorsunuz. Ve zaten bazı iyi önerileriniz vardı.

Bu görüntülere nasıl hizmet ediyorsunuz? Bunları PHP ile yayınlıyorsanız, zaten oluşturulmuş olsalar bile çok kötü bir şey yapıyorsunuz.

ASLA PHP İLE AKIŞ GÖRÜNTÜLERİ. Kullandığınız yöntem ne olursa olsun sunucunuzu yavaşlatacaktır.

Bunları anlamlı bir URI ile erişilebilir bir klasöre koyun. Sonra onları doğrudan gerçek URI'leri ile arayın. Eğer sinek üretimi gerekiyorsa, sadece istek görüntü eksikse bir jeneratör php-script yönlendirir görüntüler dizinine bir .htaccess koymak gerekir. (buna istek üzerine önbellek stratejisi denir).

Bunu yapmak php oturumu, tarayıcı-proxy, önbellekleme, ETAGS, hepsini bir anda düzeltir.

WP-Supercache düzgün yapılandırılmışsa bu stratejiyi kullanır.

Bunu bir süre önce yazdım ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), son düzeltmeler bozuldu, ancak sanırım 8 veya daha azı çalışmalı ve (.htaccess'i yapılandırmak için kullandığımdan daha iyi yollar olsa da).

Bu stratejiyi bu blog yazısında açıkladım ( http://www.stefanoforenza.com/need-for-cache/ ). Muhtemelen kötü yazılmıştır, ancak bazı şeyleri açıklığa kavuşturmaya yardımcı olabilir.

İlave okumalar: http://meta.wikimedia.org/wiki/404_handler_caching