Ben nginx / php-fpm / vernik / wordpress ve amazon s3 runnning bir sistem var.

Şimdi sistemi kurarken birçok yapılandırma dosyasına baktım ve hepsinde böyle bir şey buldum:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

Bunun neden yapıldığını anlamıyorum. Örneklerin çoğu NginX'i bir web sunucusu olarak da çalıştırır. Şimdi soru şu, neden bu statik dosyaları önbelleklemek için vernik önbelleğini kullanasınız?

Sadece dinamik dosyaları önbelleğe almak benim için çok daha mantıklı.

Doğru muyum yoksa burada bir şey mi eksik?

GÜNCELLEME

Verilen cevaba dayanarak soruya biraz bilgi eklemek istiyorum.

İçeriğin gerçekten çok değiştiği dinamik bir web siteniz varsa, chaching mantıklı değildir. Ancak, örneğin statik bir web sitesi için WordPress kullanıyorsanız, bu uzun süre önbelleğe alınabilir.

Bununla birlikte, benim için daha önemli olan statik mutabakat . Farklı önbellek uygulamalarında ve web sunucusu uygulamalarında bazı testler ve karşılaştırmalar içeren bir bağlantı buldum.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX, statik içeriğinizi elde etmede aslında daha hızlıdır, bu yüzden geçmesine izin vermek daha mantıklıdır. NginX statik dosyalarla mükemmel çalışır.

-

Bunun dışında, çoğu zaman statik içerik web sunucusunun kendisinde bile değildir. Çoğu zaman bu içerik bir yerde bir CDN'de saklanır, belki AWS S3, böyle bir şey. Vernik önbellek statik içerik depolamak istediğiniz son yer olduğunu düşünüyorum.

Verniğin birkaç avantajı vardır. İlk not ettiğiniz bir arka uç sunucusundaki yükü azaltmaktır. Genellikle dinamik olarak oluşturulan ancak nadiren değişen içeriğe önbellekleme (ne sıklıkta erişildiğine kıyasla). Wordpress örneğiniz göz önüne alındığında, çoğu sayfa muhtemelen çok sık değişmez ve sayfa değiştiğinde vernik önbelleğini geçersiz kılmak için bazı eklentiler vardır (yeni yayın, düzenleme, yorum vb.). Bu nedenle, süresiz olarak önbelleğe alırsınız ve değişiklik sırasında geçersiz kılınır - bu, arka uç sunucunuza minimum yük ile sonuçlanır.

Bağlantılı makale dayanmaz, çoğu insan Varnish düzgün kurulursa Nginx'ten daha iyi performans gösterdiğini önerebilir - ancak (ve gerçekten itiraf etmekten nefret ediyorum) - kendi testlerim nginx'in statik bir dosyayı vernikten daha hızlı sunabileceği konusunda hemfikir gibi görünüyor ( Neyse ki, bu amaçla vernik kullanmıyorum). Sorunun Varnish kullanmanız durumunda kurulumunuza fazladan bir katman eklediğinizi düşünüyorum. Bu ekstra katmandan arka uç sunucusuna geçmek her zaman doğrudan arka uçtan sunmaktan daha yavaş olacaktır - ve bu yüzden Vernik'in önbelleğe almasına izin vermek daha hızlı olabilir - bir adım kaydedersiniz. Diğer avantajı disk io ön tarafındadır. Malloc kullanmak için verniği ayarlarsanız, diske hiç vurmazsınız, bu da diğer işlemler için kullanılabilir olmasını sağlar (ve genellikle işleri hızlandırır).

Performansı gerçekten ölçmek için daha iyi bir karşılaştırmaya ihtiyaç olacağını düşünüyorum. Aynı tek dosyayı tekrar tekrar talep etmek, odağı web sunucularının kendisinden uzaklaştırmaya başlayan dosya sistemi önbelleklerini tetikler. Daha iyi bir kıyaslama, gerçekçi trafiği simüle etmek için birkaç bin rasgele statik dosya (muhtemelen sunucu günlüklerinizden bile) kuşatma kullanır. Muhtemelen, bahsettiğiniz gibi, statik içeriği bir CDN'ye boşaltmak giderek yaygınlaştı, bu da Vernik'in muhtemelen başlamak için hizmet etmeyeceği anlamına geliyor (S3'ten bahsediyorsunuz).

Gerçek dünya senaryosunda, muhtemelen bellek kullanımınıza öncelik verirsiniz - öncelikle dinamik içerik, çünkü üretilmesi en pahalı olanıdır; ardından küçük statik içerik (örn. js / css) ve son olarak resimler - gerçekten iyi bir nedeniniz olmadıkça muhtemelen bellekteki diğer medyaları önbelleğe almazsınız. Bu durumda, Varnish dosyaları bellekten yüklerken ve nginx onları diskten yüklerken, Varnish büyük olasılıkla nginx'i gerçekleştirecektir (nginx'in önbelleklerinin yalnızca proxy ve fastCGI için olduğunu ve varsayılan olarak disk tabanlı olduğunu unutmayın. memcached ile nginx kullanmak mümkündür).

(Benim hızlı - çok kaba, herhangi bir güvenilirlik verilmeyecek - test nginx'in (doğrudan) en hızlı olduğunu gösterdi -% 100 diyelim, vernik (malloc ile) biraz daha yavaş (yaklaşık% 150) ve verniğin arkasında nginx ( En yavaş (% 250 civarında), arka uçla iletişim kurmak için ekstra zaman (ve işleme) ekleyerek kendisi için konuşuyor - ya da hiçbir şey için konuşmuyor, sadece Vernik kullanıyorsanız ve yedeklemek için RAM'in olduğunu önerir. , nginx'e geri dönmek yerine yapabileceğiniz her şeyi önbelleğe alabilir ve Varnish'ten sunabilirsiniz.)

Sanırım bir şey eksik olabilirsiniz.

Tanım gereği dinamik dosyalar değişir. Genellikle, kullanıcıya sunulan sayfanın içeriğini etkileyen bir tür veritabanı sorgusu yaparak değişirler. Bu nedenle, dinamik içeriği önbelleğe almak istemezsiniz. Bunu yaparsanız, statik içerik ve yanlış içeriğe sahip büyük olasılıkla statik içerik haline gelir.

Basit bir örnek olarak, giriş yapmış kullanıcının kullanıcı adının sayfanın üstünde olduğu bir sayfanız olduğunu varsayalım. Bu sayfa her yüklendiğinde, uygun adın görüntülenmesini sağlayan sayfayı isteyen oturum açan kullanıcıya hangi kullanıcı adının ait olduğunu belirlemek için bir veritabanı sorgusu çalıştırılır. Bu sayfayı önbelleğe alacak olsaydınız, veritabanı sorgusu olmaz ve tüm kullanıcılar sayfanın üstünde aynı kullanıcı adını görür ve büyük olasılıkla kullanıcı adı olmayacaktır. Her kullanıcıya uygun kullanıcı adının gösterildiğinden emin olmak için her sayfa yüklemesinde bu sorgunun gerçekleşmesi gerekir. Bu nedenle önbelleğe alınamaz.

Bu mantığı, kullanıcı izinleri gibi biraz daha sorunlu bir şeye genişletin ve dinamik içeriğin neden önbelleğe alınmaması gerektiğini görebilirsiniz. Veritabanına dinamik içerik vurulmazsa, CMS'den sayfa isteyen kullanıcının o sayfayı görme izni olup olmadığını belirleme olanağı yoktur.

Statik içerik, tanım gereği, tüm kullanıcılar için aynıdır. Bu nedenle, bu sayfayı her kullanıcı için özelleştirmek için hiçbir veritabanı sorgusunun gerçekleştirilmesine gerek yoktur, böylece gereksiz veritabanı sorgularını ortadan kaldırmak için önbelleğe almak mantıklıdır. Görüntüler, statik içeriğin gerçekten harika bir örneğidir - tüm kullanıcıların aynı başlık resmini, aynı giriş düğmelerini vb. Görmesini istersiniz, bu nedenle önbelleğe almak için mükemmel adaylardır.

Yukarıdaki kod snippet'inizde, görüntülerin, css ve javascript'in önbelleğe alınmasını zorlayan çok tipik bir Vernik VCL snippet'i görüyorsunuz. Varsayılan olarak, Vernik içinde çerez bulunan hiçbir isteği önbelleğe almaz. Mantık, istekte bir çerez varsa, sunucunun bu çereze ihtiyaç duymasının bir nedeni olmalı, böylece arka uçta gereklidir ve önbellekten geçirilmelidir. Gerçekte, birçok CMS (Drupal, Wordpress, vb.), Gerekip gerekmediği hemen hemen her şeye çerezler ekler, bu nedenle çerezleri statik olduğu bilinen içerikten çıkarmak için VCL yazmak yaygındır ve bu da Verniğin önbelleğe almasına neden olur o.

Mantıklı olmak?

İçin dinamik içeriklerin , hisse senedi fiyatları aslında sık sık değiştirmek gibi bir çeşit (bir de her saniye güncellenen SaaS serverbir den backend server) ama (onbinlerce hatta daha sık sorgulanan olabilir subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

Bu durumda, önbelleğe üzerine SaaS servergelen başına ikinci güncelleme backend serversyapar mümkün onbinlerce ait sorguları tatmin etmek subscription users.

SaaS sunucusunda bir önbellek olmadan bu model işe yaramaz.

Statik dosyaların Varnish ile önbelleğe alınması, Nginx'in boşaltılması açısından fayda sağlayacaktır. Elbette, önbelleğe alınacak çok sayıda statik dosyanız varsa RAM'i boşa harcar. Bununla birlikte, Varnish'in güzel bir özelliği var - önbelleği için birden çok depolama arka ucunu destekliyor.

Statik dosyalar için: HDD'ye önbellek Diğer her şey için: RAM'e önbellek.

Bu size bu senaryoyu nasıl uygulayacağınız konusunda daha fazla fikir verecektir: http://www.getpagespeed.com/server-setup/varnish-static-files-cache