Webde yüksek verim nedir ve genel olarak kullanılan cache(ön bellek) sistemleri nelerdir biraz bakalım. Cache dediğimiz konu aslında temel olarak webdeki program, web server veya database’in üstüne düşen yükün azaltılarak kullanıcıya daha hızlı şekilde verilmesi esasına dayanır.Yazıyı normalde üç veya dört parçaya bölmeyi düşünmeme rağmen konunun bütünlüğünün bozulmaması için çok fazla bölmemek gerektiğini düşünüyorum. Basitten gelişmiş anlatıma doğru giderek, sadece memcache konusunun detayı fazla olduğu için memcache konusunu farklı bir başlık altında anlattım. Bu yazıda ise biraz daha özet olarak memcache’den bahsedeceğim. Yazıda her dile uygun olabilmesi için, code örnekleri yerine genel olarak yapıyı sorunları ve cözümleri anlatmaya çalıştım. Genede PHP ağırlıklı bir yazı olduğunuda kabul etmek gerekiyor.Cache sistemleri kullanırken genel olarak altın kural diyebileceğim dört tane durumu akıldan çıkarmamak gerekiyor.• Cache sistemleri asla bir veritabanı değildir, cache’e eklediğiniz bir verinin illaki orada olmasını bekleyemezsiniz. Dolayısıyla programınızı cache’deki verinin asla kaybolmayacağını düşünerek yazmamak gerekmektedir.
• Program yazarken cache konusunu her zaman düşünmek ama cache yokken çalışabilmesini sağlamalıyız. Program yazımına başladığınızda en baştan yüksek verimliliği göz önünde bulundurarak, cache olacağını akılda tutarak yazmak ama programın cache olmadan çalışabileceği esasına dayanmak gerekmektedir.
• Cache’lerde invalidate etmeyi eğer siteniz büyümeye yatkınsa tek server üstünden düşünmemek gerekir. Eğer web sitenizin kullanıcısının artacağını düşünüyorsanız, birden çok web ve/veya database server’ın işin içine gireceğini en baştan düşünmelisiniz.
• Veri tabanını programınızda kullanımınız eğer okumaktan çok daha fazla yazmak üzerineyse dinamik cache kullanmanız çok mantıklı değildir.
Cache sistemlerini sanırım statik ve dinamik olarak iki grup altında toplayabiliriz.Statik Dosyaların Cache’lenmesi:
Statik dosya cache inin içine neler giriyor diye düşünürsek, değişmeyen html dosyalarınız javascript dosyaları, imajlar, videolar, css dosyaları.. gibi gidebiliriz. Statik cache her zaman dinamik cachelenmeye göre daha hızlıdır. Bu yapının içine daha çok web browserlar, proxyler ve web serverlar girmektedir.Dinamik Verilerin Cache’lenmesi:
Benim tüm sayfam dinamik hiçbir şeyi cache’leyemem. Evet bu oldukça çok duyduğumuz bir söz ama maalesef doğru değildir. Sayfanızın belirli elemanları her zaman aynı kalmaktadır. Veri tabanından genel olarak çektiğiniz ve gösterdiğiniz veriler aynı olacaktır. Aradaki 5 saniye bile cache yapsanız web sitenize giren kişi sayısı saniyede 100 kullanıcı bile üzerindeyse çok ciddi avantaj sağlayacaktır. (Bu rakam büyük sitelerde 1000, 2000 gibi sayılara çok rahat ulaşabilmektedir) Bu konu altına cookie, memcache, file, apc (veya benzeri shared memory uygulamaları, çözümleri) gibi cache çözümleri girmektedir.Statik Dosya Cache:
Browser Cache:
Öncelikle browser cache den bahsedelim. Web serverınıza düşen yükü azaltmanın yegane yolu budur aslında, yeni nesil browserlar siz client(istemci) tarafında aksini yapmasını söylemediğiniz sürece web server’ın verdiği şartlara uygun olarak dosyalarınızı cache’lerler. Bu cache sistemi RFC 2616 ya göre gönderdiğiniz header bilgilerine göre işlemektedir. Bu işi genel olarak apache, lighttpd, nginx gibi web serverlar doğru şekilde ayarlarsanız sizin üzerinizden alarak otomatik yapabilmektedir. Apache web server’da mod_expires, lighttpd web server’da mod_expire , nginx web server’da da expires komutu ile yapılabilmektedir.Browser cache in genel problemi ise, gelişen web sitelerinde static dosyaların dahil her zaman değişime maruz kalması zorunluluğudur. Karşımıza şöyle bir problem çıkmaktadır. Örneğin kullanıcı avatarını değiştirdiğini varsayarsak, eski resim artık geçersiz olsa bile kullanıcılarınız cache süresi dolana kadar eski resmi görecektir.Bu sorunu çözmek için ise statik dosyalara isim verirken timestamp eklemek yada belirli bir id yi her defasında artırarak dosya ismine eklemekten geçmektedir. Örneğin eğer kullanıcı ikinci sefer avatar değiştiriyor ise nick-id.jpg seklinde kaydederken eğer ikinci avatar değişimi ise “darkelf-2.jpg” gibi kaydetmek sorunu cözecektir. Aynı durum sitenizdeki javascript dosyaları içinde geçerlidir. Eğer dosyayı upload ettiğiniz tarih + o gune ait bir idyi dosya ismine eklerseniz bu sorunu cözebilirsiniz örneğin “hede-2008112201.js” şeklinde isimlendirebilirsiniz.Programı yazan kişinin en baştan bu duruma uygun şekilde programı yazması gerekmektedir. Yoksa çok ciddi bir emek kaybı ile programın değişimi söz konusu olması gerekebiliyor.Proxy Serverlar:
Her programın olduğu gibi web server’larında kendisine özgü limitleri olduğu tartışılmaz bir konu. Dolayısıyla static dosyalar için web serverların üstündeki yükü düşürebilmek için reverse proxy server mantığını kullanmanız gerekmektedir.Reverse proxy ler nasıl çalışır kısaca değinmek gerekirse kendisi üzerine bir istek geldiğinde ilk önce kendi cache’inde varmı diye bakar, varsa kendisi üzerinden hiç web servera sormadan verir, eğer yok ise web serverdan çekmeye başlar ve bu sırada kullanıcıyada gönderir ve ardından bu dosyayı tekrar istendiğinde vermek üzere kendi üstünde saklar.Reverse Proxy Server’ların bir dosyayı invalidate etmesi genel olarak ekstradan üstün gelen (override) bir ayar yapmadıysanız browser cache için gönderdiğiniz ayarları kullanır. Proxy serverlardan genel olarak benim gördüğüm en verimli çalışan iki tanesi Squid ve Varnish oldu. İkisinin de kendisine özgü avantajları bana göre farklı şekildedir.Squid proxy yapısında birden çok proxy serverın ortak çalışmasını sağlayabiliyorsunuz. ( – bende varmı? Yok. – Sende varmı varsa gönder ? Yok. – Sen bana şundan alıp versene gibi bir mantık dizisi içerebiliyor). Ayar yapması gerçekten zordur. Squid sistemi çok eski yıllardan beri var olduğu için işletim sisteminde sorun olan konuları kapatmaya göre çalışmaktadır. Memory allocation yapısını kendisi oluşturur. IO Systemi yönetir yani işletim sisteminin arkada yaptığı tüm işleri tekrar yapar ve buda sisteme ciddi bir overload yapmaktadır.
Varnish Proxy ise daha yeni bir proxy yapısı olduğu için farklı bir yapı kullanmış. İşletim sistemleri artık üstlerindeki işi en doğrusu ile yaptığını düşünerek(Evet o kadar kernel developer boş durmamaktadır) sistem ile dövüşmeden user space de programın kendisine düşen yükü mümkün olduğunca en aza indirerek bu işi yapmaktadır. Biraz teknik konuya girersek, Shared Memory doğru kullanımı tek bir bufferın tüm connectionlara hizmet verebilmesi gibi örnekler sayılabilir. Artı bir avantajı kendi içinde libgcc ile C dilinde script tarzı yazmanızı ve kendisinin bunu .so dosyasına çevirip yükleyebilmesini sağlamaktadır. Buda proxy i istediğiniz tarzda yönlendirebilmenizi yönetebilmenize izin veriyor, henüz bildiğim kadarıyla multi server’ın ortak çalışma özelliği yok.
Yaptığım testlerde bu iki yapının da küçük dosyalarda oldukça verimli iken dosyalar büyüdükçe (1M ve üzeri) , istek çoğaldıkca yada partial download çoğaldıkca sorunlar çıkardığını gördüm. Bu durum sizekendi proxy server’ınızı yazmaya kadar itebilmektedir.Web Serverlar:
Proxy serverlar ile uğraşmak istemediğinizde bir başka çözüm ise normal kullandığınız application serverların yanına static dosyalar için daha lite(hafif) web serverlar koymaktır. Bunlara örnek olarak thttpd, lighttpd verilebilir. Bu Web serverların işlevi sadece statik dosyaları vermek olduğundan hem application serverdaki yükünüz azalır hemde daha hızlı şekilde dosyaları kullanıcıya ulaştırabilirsiniz. Ancak invalidate etme konusu ayrı bir sorundur ve dosya sayısı çoğaldıkça başka sorunlara yol açabilir. Dosyaların geç değişmesi kopyalamanın çok uzun sürmesi gibi.Buraya kadar anlattığım konular statik dosyalar içindi. Ne yazıkki sadece bunları yapmak verimli bir web uygulamanız olacak demek değildir. Dinamik caching büyüyen sitelerde mecbur kalınan bir yapıdır.Dinamik Cache:
Cookies:
Coğu süreçte güvenlik yada session amaçlı kullandığımız cookie ler aslında caching sistemlerinin vazgeçilmez bir parçasıdır size kullanıcı sayfa isteği gönderirken zaten sizin database’den o kullanıcıya özgü çekmek zorunda olduğunuz verileri göndermesini sağlayabilirsiniz.Örnek vermek gerekirse web uygulamanızda mesajlaşma yorum yazma gibi konuların olduğunu ama yorum yazılacak profil sahiplerinin kendisine yorum yazamayacak kişileri seçebildiğini düşünelim. Bu durumda daha liste sayfasını oluştururken bile kullanıcının yorum yazamayacağı sayfalardan linkleri kaldırmanız gerekebilmektedir. Bu durumda web uygulamanızın yapması gereken şey ise listelediği kişi başına gezen kişinin mesaj atıp atamayacağını database yada diğer cache sistemlerinden sorgulamak olmaktadır. Veri tabanını buna özgü doğru şekilde tasarlamış tek sorguda yazamayacağı profilleri alabiliyor olsanız bile her şart altında bu bir yük oluşturmaktadır. Sayfayı gezen kişiye henüz cookiesi boş iken bu bilgiyi göndermek için Veri tabanından yada cache sisteminizden aldığınızı düşünelim sayfayı gösterirken cookie’yi kullanıcının makinesine atarsak eğer bir dahaki benzer profilleri gezdiğinde zaten daha bize istek sırasında gönderemeyeceği kişileri gönderecektir. Buda bizi gereksiz bir sorgudan kurtarmış olur. Genede güvenlik için cookie lere bel bağlayamazsınız gelen cookie içinde olmayan profilleri veritabanından test etmeniz her şartta gerekmektedir. Başta kücük bir getiri olarak gözükse bile web sayfanızda saniyede 100 lerce farklı kullanıcının aynı saniyede bu sayfaları çağırdığını düşünürseniz getirisi inanılmaz derecede fazla olacaktır.Cookie ler limitsiz değildir. Domain başına atabileceğiniz cookie sayısı ve büyüklüğü rfc ye göre en az 50 cookie ve cookie başına 4096 byte iken, durum daha çok browser specific’dir. Bildiğimiz kadarıyla browser’ların domain başına tutabileceği cookie sayısı;* Patchlenmemiş Internet Explorer 6: 20 cookie , toplamda 4096 byte* Patched Internet Explorer 6: 29/08/07 tarihinde microsoft 20 cookie yi 50 cookie’ye çıkarmış ama toplam limiti 4096 bırakmıştır.* Internet Explorer 7: 50 cookie, 4096 byte toplamda* FireFox > 1.5: 50 cookie, 4096 byte cookie başına* Opera: 30 Cookie* Safari: 1000 ve üzeri, 4096 byte cookie başınaBu limitleri cookie yazmadan önce hesaplamanız gerekmektedir. Eğer Internet Explorer 6 da 4096 byte’ı geçerseniz yeni cookie eklenmesine izin vermemektedir. Bu Cookie size a session id gibi cookielerinde dahil olduğunu unutmamak gerekmektedir. User Agent’a bakılarak browser’a özgü cookie ataması yapmak buradaki en doğru çözümlerden birisidir. IE6 ve IE7 de kullanmamayı lütfen planlamayın, hala türkiyedeki büyük çoğunluk Internet Explorer 6 kullanmaktadır.Cookie leri kullanmamız gerekmektedir ancak dikkat edilmesi gereken bir konu bu cookielerin boyutunu büyültmenin götürüsü arasında sadece internet explorer 6 ve 7 deki sorunları değil aynı zamanda kullanıcı her sayfanızı çağırışında size cookie boyutu kadar bir veriyi göndermek zorunda bırakmanız belirli ölcüde request zamanını ve dolayısıyla sayfanızın kullanıcıya geliş hızını düşürecektir. Dolayısı ile doğru ve gerekli şekilde cookieleri kullanmak her zaman için avantajdır.File Cache:
Sayfalarınızı dinamik oluşturduğunuz süreçleri genel olarak azaltmanın en çok kullanılan yollarından birisidir. Sayfada bir değişiklik olmadığı süreçte sayfa dinamik olarak hazırlandıktan sonra bir dosyaya kaydedilerek sonraki çağırımlarda, o sayfanın statik bir html dosyasından okunarak verilmesi esasına dayanır. Bir değişiklik yapıldığında ise o sayfa tekrar yartılarak yeni isteklere hazır hale getirilir. Eğer sayfamda her daim değişen bir şeyler var diyorsanız değişmeyen kısımlarını birkaç dosyaya bölmeniz o dosyaları oluşturmanız için gereken Veritabanı erişimlerini azaltacağı için ciddi avantaj sağlayacaktır yani web sayfasını olduğu gibi tek bir dosyada tutmanız her zaman olası değildir.Ne yazıkki file cache sorunsuz değildir, birkaç genel problemi vardır. Bunlardan ilki disk’e bağımlı olduğunuz için diğer cache sistemlerine göre daha yavaş çalışıyor olmasıdır. Diğer bir noktasıda filecache oluşturma sürecini atomic(Bir anda) yapmak zorunda olmamız, yani biz sayfayı oluştururken kullanıcı gelirse o sayfanın yarıda kalmış eksik halini görmemesi gerekir. Cözümü genel olarak başka bir dosya adı ile oluşturup adını olması gereken dosyaya çevirmektir. Directory başına oluşturduğunuz cache file sayısıda bu konuda sisteminizin yavaşlaması için etkendir. Belirli bir hashing algoritmasına göre alt directory’lere bölmeniz gerekmektedir. En önemli sorunu ise eğer birden çok web serverınız varsa iki ayrı sistemin invalidate etme durumlarında ortak çalışmaması olacaktır. Bu konuda maalesef samba nfs tarzı paylaşımlı directory kullanmak verimi dahada düşürüp network yapınız üzerine yük bindireceğinden kullanmamak gerekir. En doğru yöntemi ise biraz alt düzey yapı oluşturarak bir deamon aracılığı ile değişiklikleri kontrol edip invalidate olmuş cache dosyasını silmektir yada bu işi memcached gibi network üstünden çalışan sistemler ile invalidate kontrollu hale getirmektir.Tek başına file cache kullanımı disk ömrünüzden yiyeceğini unutmamak gerekir ve örnek vermek gerekirse 1 milyon farklı sayfanız varsa 1 milyon dan biraz daha fazla cache dosyanız olacak demektirki buda file system için ciddi bir sorundur.Memcache:
Memcache danga.com tarafından live journal için üretilen ama yapısı itibari ile çok hızlı şekilde popüler olmuş bir cache yapısıdır. En büyük avantajı network üstünden çalışabilmesidir, Network üstünden tcp/ip ile çalıştığı için file cache e göre daha yavaştır ancak ortak cache havuzunu kullanabiliyor olmanız gibi avantajları ve SQL serverlara göre çok daha hızlı olması sebebi ile ciddi tercih sebebidir. İçerisinde her türlü veriyi saklayabilmenizi sağlar. Atomic inc ve dec gibi fonksiyonlarıda ciddi bir avantaj sağlamaktadır.Anahtar ve veri şeklinde çalışmaktadır. Hız sebebiyle iteration yapılamamaktadır. Örnek verirsek eğer bir kullanıcınızın sayfası çok fazla istek alıyor. O kullanıcıya özgü verilerin her sayfa çağrışında veritabanından birden çok veri tabanı sorgusu ile okunması yerine kullanıcının id’sini anahtar olarak düşünüyoruz ve veri tabanından ilk seferinde çektiğimiz gerekli bilgilerini bu anahtar aracılığı ile memcache e kaydediyoruz. Ardından bir sonraki sayfa çağrıldığında memcache de gerekli bilgiler olduğu için veri tabanına birden çok sorgu göndermeden tek seferde bu veriye ulaşabilmekteyiz ve tüm web serverların aynı ortak cachei paylaşıyor olmasından dolayı çok ciddi şekilde veri tabanına düşen yük azalacaktır.Dezavantaj olarak söyleyebileceğim noktası ise hız sağlamak için kullanılan slab allocation yapısının eğer düzgün kullanılmazsa sorunlar yaşatıp gereksiz memory kullanabileceği ve veriminin düşeceğidir.Memcache konusu biraz geniş olduğu için bundan sonraki yazıda daha çok detayına gireceğim.Shared Memory:
Şimdi anlatacağım APC, Xcache, Eaccelerator gibi programlar ve Global variable kullanmak php development’a yöneliktir. Şirketimizin scability açısından genel olarak PHP’yi tercih ettiği için bu konularda genel olarak asp,ruby veya benzeri sistemler yerine PHP üzerinde araştırma ve geliştirme yapmaktayız.Global Variables:
Evet bildiğimiz global variable’lar projeler büyüyüp üzerinde çalışan kişi çoğaldıkca ve library bazında sistemler yazılmaya başlandıkca çok ciddi önem kazanmaktadır ve cache sistemi olarak kullanılabilmektedir. Direk uygulama içinde olduğu için diğer sistemlere oranla en hızlı çalışan cache sistemidir.Nasıl kullanıldığına örnek olarak bir sayfada birden çok SQL kullanmanız gerekmektedir. Kullanıcının son yazdığı entry i birden çok functionda kullandığımızı düşünelim. Eğer birden çok developer programın farklı yerlerini yazıyor veya yazdıysa birbirlerinden habersiz olarak aynı değerleri aynı php sayfasında bile cache sistemlerinden yada veri tabanından çekme olasılıkları çok yüksektir. Bu durumu yok etmek için cache yapısında kullandığımız anahtar mantığını global variable olarak düşünelim cache den veya veritabanından ilk çektiğimizde $GLOBALS[‘userid:darkelf’] = diye atama yapıyoruz. Ardından başka bir fonksiyonumuz aynı değere ihtiyaç duyacak olduğunda cache sistemlerine ve veritabanına sormadan önce anahtarı bildiğimiz için $GLOBALS da varmı diye bakıyoruz. İlk başta oldukça gereksiz bir yöntem olarak gözüksede projeniz büyüyüp birden çok kişi üzerinde çalışmaya başladığında tekrar tekrar çekilme olasılığını yok ettiği için olmazsa olmaz bir yapıdır.APC, Xcache ve Eaccelerator libraryleri ve shmop_* functionları:
Bu 3 opcode cacher ve shared memory managerı sanırım aynı başlık altında toplamak daha mantıklı olacak. 3 ününde yaptığı iş aynı olsada yapış şekilerinde ve hızlarında farklılıklar vardır ve projeniz için birisinden birisini tercih etmeniz gerekmektedir. 3 ününde kendine özgü avantajları ve dezavantajları vardır.Bu librarylerin asıl görevi opcode caching dir. Bu ne demek siz bir php sayfasını çağırdığınızda PHP bu sayfanın codelarını her defasında kendi çalıştırabileceği hale getirmek için kendi opcode yapısına göre derler yani hafızada scriptler basic,qbasic zamanlarında olduğu gibi satır satır okunarak çalıştırılmaz. Önce tüm script okunur ve parsing in hız götürmeyeceği şekilde genelde instruction set’lerin 2 byte tutacağı hale çevrilir ve hafızada bu şekilde çalıştırılır. Oldukça doğru bir yöntem olmasına rağmen buradaki asıl sorun her sayfa çağrıldığında bu scriptlerin tekrar tekrar derlenmesi aslında gereksiz bir yöntemdir. PHP dosyaları cünkü çalışırken zaten bir değişime girmemektedir. Bu 3 library bu durumda kendilerine özgü hem php nin ürettiği opcode’u optimize eder, hemde php sayfaları çağrıldığında tekrar tekrar scriptlerin derlenmesi yerine php’ye kendi hafızalarından derlenmiş halini vererek aradaki derleme sürecini yokeder. PHP ile kod yazıyorsanız opcode cacher kullanmamanız için hiçbir sebep yoktur ve kullanmıyorsanız bu sizin sorununuzdur.Bu library ler opcode caching harici ayırdıkları hafızayı php ye library olarakda sunmaktadır yani uygulamanızda bir classın içeriğini, değişkeni yada herhangi bir veriyi ortak şekilde kullanabilmektesiniz. shmop_* functionları ile bu işi ben zaten yapıyorum diyorsanızda maalesef tuttuğunuz veriler çoğaldıkca shmop_* daki kullandığınız memory üzerine index mantığı getirmeniz gerekmektedir. Ne kadar doğru şekilde kodlarsanız kodlayın bu library’lerin bu işi yaptığı kadar hızlı ve doğru yapamayacaksınızdır. (C , PHP farkı) Bu yüzden shmop_* functionlarını kendi adıma bu library’ler varken kullanmanızı tavsiye etmiyorum.Bu 3 library de memcache gibi anahtar ve veri yapısını kullanmaktadır, web üzerinden PHP çalıştırmanın bildiğiniz üzere apache kullanarak shared library şeklinde, FastCGI arabirimi ile ve CGI olarak üç yolu vardır. CGI kullanıyorsanız eğer shared memory kullanmanızın hiçbir mantığı yoktur. Çünkü her sayfa çağrıldığında yeni bir php process’i yaratılacaktır ve ortak hafıza kullanamayacaktır. FastCGI ve shared library de ise durum farklıdır ve opcode cacherları bu iki arabirim sebebiyle daha çok kullanıma özgü ayırabiliriz.Opcode cacher lardaki genel bir sorun opcode cache kullanıyorsanız önemlidir. Eğer sayfanızdaki ziyaretciye özgü require yapıyorsanız örneğin eğer admin ise su dosyayı include et tarzı, opcode cacherlar oluşan compiled code değiştiği için her sayfanın farklı kullanıcı yapısına göre yüklendiğinde tekrar derlemek zorunda kalacaktır. Bu da opcode caching i CPU hungry duruma getirecektir.APC(Alternative PHP Cache) yaptığımız testlerde memory allocationdaki farklı yöntemi ile en hızlı çalışan opcode cacher ve library’dir. PHP 6 da standart olarak gelmesini düşünülüyor. Genel olarak dezavantaj diyebileceğim noktalar ise top level parent process e ait shared memory kullanmadığı için FastCGI tarzı yapılarda FastCGI daki PHP lerin respawn ömrü sonlandığında hafızayı boşaltması ve her FastCGI dan spawn olan PHP için ayrı birer shared memory kullanmasıdır. Bu durum php lerin opcode cacheleri icinde geçerli olduğundan web server’ınızın yükünü artırdığı gibi memory kullanımınızda artacaktır. Bunun harici memory allocation yapısındaki garbage collector tarzı ara ara temizlik yapması gerektiğinden FastCGI olsun olmasın ara ara web serverın cpu’sunu tavan yaptıracaktır. Turkish UTF Encoding ile ilgili sorunları olduğunuda projelerimizde gördük. FastCGI kullanıldığında bu durumda birden çok cache oluştuğu için Invalidate etmedede sorun çıkacaktır.Eaccelerator apc kadar hızlı olmamasına rağmen stability açısından daha sağlıklı sonuçlar doğurduğunu söyleyebilirim. Genel olarak farkı ise opcode cacheleri aynı zamanda diskede yazdığı için web server tekrar başladığında yada PHP processi tekrar başlatıldığında tekrar derlemek yerine diskden hızlıca derlenmiş halini okuyarak cpu yükünüzü azaltmasıdır. Genede fastcgi processlerinde top levent parent process e bağlanmadığı için APC gibi FastCGI da açtığınız PHP process’i başına ayrı memory tüketecektir ve sonlanacaktır. Haliyle bir web serverda birden çok cache yapınız ve farklı değerleri olabilecektir.Xcache lighttpd developerlarının çıkardığı daha yeni gelişen bir opcode cacher ve shared memory library’dir. Genel Olarak APC yada Eaccelerator’a göre daha yavaş çalışsada FastCGI processlerinde top level parent process e shared memory’i bind ettiği için tüm php process’lerinin aynı shared memory’i ve opcode cache’i kullanmasını sağlamaktadır. Stabilty konusunda eski versiyon’unda baya sorunlar çıksada, bir projemizde yeni versiyon’unun uzun süredir sorun çıkarmadığını söyleyebilirim.Yaptığımız hız testlerinin sonucunuda paylaşayım, bu testler platform specificdir sonuçları sizlerin sistemde farklı çıkabilir, tavsiyem yeni versiyonları ile kendinizinde benzer testler yapmanız ve buna göre hangisini kullanacağınızı seçmenizdir.APC:Saniyede 615563 okuma yapabildi.
Eaccelerator:Saniyede 320624 okuma yapabildi.
Xcache: Saniyede 290950 okuma yapabildi.
Sonuç:
Kendi yaptığımız hız testlerini paylaşıyorum, dediğim gibi sonuçlar platform specifictir ve kendinizinde benzer testler yaparak sırayı ve nasıl bir cache sistemi oluşturacağınızı seçmeniz en doğru yoldur. Herhangi bir şekilde programları karşılaştırmak amaçlı değildir burada vereceğim değerler sadece bizde çıkan test sonuçlarıdır.Global Variables: 863856/sec
APC: 615563/sec
Eaccelerator: 320624/sec
Xcache:290950/sec
File: 48704/sec
Memcache: 35217/sec
Memcache(Multi Connection): 15230/sec
Peki hangi cache sistemi diye kendinize soruyorsanız, projenize özgü seçmeniz gerekmesine rağmen şahsi tavsiyem hepsini kullanmanızdır. Her cache sisteminin kendine özgü avantajları ve dezavantajları vardır. Doğru caching sistemi ise hepsinin ortak şekilde çalışarak en hızlı şekilde veriyi vermesi üzerine dayanır. En hızlıdan en yavaşa doğru bir yapı izleyerek cacheleri sorgulamak bu yüzden en doğru yol olarak gözükmektedir.Cache sistemlerinde dikkat edilmesi gereken en önemli noktalardan birisi uygulamanızın cache olmadığı takdirde doğru ve düzgün şekilde çalışabilmesidir. Cache sistemleri sistemin performansını server maliyetini düşürmeye yöneliktir ve her zaman olacaklar diye bir durum yoktur. Örnek vermek gerekirse google yada benzeri arama botlarının sitenizdeki daha önce kullanılmayan yada kullanıcılar tarafından çok az kullanılmış artık eskisi kadar kullanılmayan sayfaları hızlı şekilde çekmeye çalışacağıdır. Bu botların sitenizi tararken sisteminizin sorun çekmesi hem arama sonuçlarında çıkmanızı zorlaştıracak hemde sisteminizin geçici çökmelerle karşılaşmasına sebep olacaktır. Bu durum illaki arama botları değil kötü niyetli bir kullanıcı tarafındanda yapılabilecek bir konudur.Arama botları geldiğinde en önemli konulardan birisi Cache den olan varsa çekerken eğer yoksa geri global variable hariç cache’e yazmamaktır. Normal kullanıcınızın kullanmayacağı bir veriyi cache de tutup normal kullanıcınızın kullanacağı verileri cache den silmeniz sitenizi gene zor duruma düşürüp sistem sorunlarınızı artıracaktır. Bu yüzden user agent kontrol edilerek cache yapısına karar verilmesi gerekmektedir.Uygulamalarda yüksek verim sadece cache sistemlerine bağlı değildir. Kodun nasıl yazıldığından sistemin nasıl yapılandırıldığına, tasarıma kadar bir çok konuya bağlıdır. Fırsat bulursam başka yazılarda bu konulara da değinmeye çalışacağım.