memcached
-
danga interactive tarafından geliştirilmiş open source bir distributed memory object caching system
http://www.danga.com/memcached/ -
web uygulamalarinin, database'e erisimini minimize etmek icin gelistirilmistir. belirli key'leri belirtilen sureler icin cache'de tutar ve harddisk i/o islemi yapmadigi icin cok daha hizli bir sekilde [rdbms'in cache kullanmadigi varsayildigi durumda] istemciye gonderir.
slashdot, wikipedia, sourceforge, facebook, kayak, jibjab gibi yuksek miktarda hit alan bircok kurum tarafindan kullanilmaktadir. -
dunyadaki en buyuk memcached kurulumu, facebook'dadir. zaten sirket, memcached'in official gelistiricilerinden biri olmustur.
-
-
asp.net provider'ları http://www.codeplex.com/memcachedproviders adresinden edinilebilir.
-
hayvani ram'e sahip ve sık sık aktivitelerin gerçekleştiği serverlarda bulunması gereken,hayati öneme sahip hede.
hızlı olsun,sistemi kasmasın diye; arama sonuçlarının idlerini kaydetmek için kullanıyorum,tekrar tekrar database'e bağlayıp sayfalandırma yaptırmaktansa böylesi daha hızlı.
bunun bir de mysql için depolama motoru olan bir versiyonu var;select/update/insert/delete komutları çalışıyor yani;mysql de tablo ayarlarından depolama motoru seçeneğinden memcacheyi seçiyorsunuz o table'ı disk yerine ramde tutuyor... sık sık sildiğiniz , baki kalmasını istemediğiniz veriler için idealdir.
servera restart attığınızda bütün hafızasını kaybettiği için uzun süre boyunca size lazım olacak datalarınızı , memcache'lemeyin lütfen.
edit:kendisini artık session yönetimi için de kullanmayı planladığım hede. -
unutulmamasi gereken bir nokta; performans kaybi yasanmamasi icin memcached'de herhangi bir authentication/authorization mekanizmasinin implement edilmemis olmasidir. dolayisi ile bir memcached sunucusunun dinledigi porta erisebilen herkes, eger key adini biliyorsa icerigini de edinebilir.
o yuzden memcached'in calistigi sunucularin guvenligi ciddi sekilde onemlidir. -
paul saab'in facebook engineering blog'u icin yazdigi scaling memcached at facebook adli yazidan alintidir. orjinali;
http://www.facebook.com/…te.php?note_id=39391378919
adresindedir.
---------------------------------------------------------------------------------------------
eger buyuk miktarda trafige sahip websitelerini olceklendirme ile ilgileniyorsaniz, muhtemelen memcached'i duymussunuzdur. memcached, yuksek performansli bir dagitik object caching sistemidir. facebook, halihazirda memcached'in dunyadaki en buyuk kurulumuna sahip ve bu kurulumu veritabani yukunu azaltmak icin kullaniyor.
memcached, her ne kadar oldukca hizli olsa da, facebook default performanstan daha fazlasina ve daha etkinine gereksinim duyuyor. halihazirda 800 server uzerinde 28 terabyte'tan fazla hafizayi memcached icin kullaniyoruz. gectigimiz son bir sene icerisinde facebook'un buyume hizi oldukca yuksek oldugundan, baska bir cok konuda oldugu gibi memcached kullaniminda da olceklendirme sorunlari ile karsi karsiya kaldik. bu yuzden artan kullanici talebini karsilayabilmek icin hem isletim sistemi, hem de memcached kodu uzerinde degisiklikler yapmaya yoneldik.
her biri en az yuz apache processi calistiran binlerce sunucuya sahip oldugumuzdan, memcached'e baglanti kurmak icin acilmis yuzbinlerce tcp istemi ile karsi karsiya kaldik. aslinda baglanti sayisinin bu kadar yuksek olmasi tek basina bir sorun olmamakla beraber, memcached'in bu baglantilar icin hafiza ayirma sistemi sorun yaratti zira memcached default hali ile network uzerinde data transferi yapabilmek icin "her baglantiya ait bir tampon bellek" metodu ile calisiyor. yuzbinlerce baglanti sozkonusu iken bu memcached'in aslinda asil islevi olan data saklamak icin kullanmasi gereken gigabyte'lar duzeyindeki hafizanin gereksizce harcanmasina sebep oluyor. bu yuzden, memcached uzerinde tcp ve udp socket baglantilari icin "her thread icin paylasimli baglanti tampon hafizasi*" implemente ettik. bu, hafizayi cok daha etkin bir sekilde kullanabilmemizi sagladi.
her ne kadar hafizayi etkin bir sekilde kullanan tcp 'yi implemente etmis olsak da, get islemleri icin default tcp olan iletisim protokolunu udp'ye cevirdik. bu bize hem daha dusuk network trafigi hem de birden cok get islemi icin (paralel olarak yuzlerce get islemi) uygulama seviyesinde akis kontrolu sagladi.
bu islemler sirasinda farkettigimiz sey su oldu, linux yuksek miktarda yuk altinda udp performansini ciddi sekilde dusuruyordu. bunun sebebi ise, birden cok thread'in tek bir udp socket baglantisi uzerinden data transfer ederken, udp socket lock uzerinde ciddi sayida lock contention* olusmasiydi. kernel uzerinde her lock'i ayri ayri handle edecek degisikligi yapmak pek kolay olmayacagi icin, isteklere cevap verirken her thread icin ayri socket acma yoluna gitmeyi tercih ettik. boylece performanstan odun vermeden udp'ye gecebilme olanagi sagladik.
linux uzerinde gordugumuz baska bir sorun ise, bir cekirdegin surekli network soft interrupt islemleri ile bogusmak zorunda kalmasi ve baska is yapamaz olmasiydi. linux, bir cekirdek secerek network interrupt islemleri icin sadece o cekirdegi kullanmayi tercih ediyor. ayrica, rastladigimiz baska bir bulgu ise belirli network kartlarinda, asiri miktarda interrupt olusmasiydi. bu sorunlari cozmek icin network arayuzunun "oportunistik" polling'ini tercih ettik. bu model, network i/o islemleri icin interrupt driven ve polling driven yontemlerinin kombinasyonundan olusuyor.
ag arayuzunu herhangi bir zaman diliminde network surucusu aktif oldunda (genellikle bir paket transmit ederken) ve process scheduler'in idle dondugusunden poll ediyoruz. ek olarak, gecikmeleri azaltabilmek icin interrupt almakla beraber, defaulta gore cok cok daha az miktarda aliyoruz. (tipik olarak interruptlara ait bilesik esikleri agresif olarak belirleyerek).
bunlarin sonucunda, hem ag iletim islemlerini tum cekirdekler uzerinde yaptigimizdan ve network i/o islemlerine yonelik polling'leri process scheduler'in idle dongusunden hallettigimizden, network islemlerini tum cekirdekler uzerinde hemen hemen esit sekilde dagitabiliyoruz.
son olarak, yaptigimiz testlerde 8 cekirdekli sunucular kullandigimizda, yeni darbogazlarla karsilastik. ilk olarak, memcached'in stat collection islemi, global lock'a bagimliydi. sonuc olarak 4 ve 8 cekirdekli sistemlerde lock islemleri %20 - %30 cpu zamanina maloluyordu. bu sorunu stats collection islemleri her thread basina yaparak ve sonuclari istek uzerine toplu bicimde sunarak cozduk. ikinci olarak ise, udp paketlerini ileten thread sayisini arttirdikca, her bir network aygitinin transmit kuyrugunu koruyan kilit uzerindeki lock contention'in hatiri sayilir bir sekilde arttigini ve sonuc olarak performansin dustugunu farkettik.
paketler default olarak transmission tarafindan kuyruga atilip, aygit surucusu tarafindan kuyruktan cikarilir. bu islemler, linux'un ip ve aygit surucusu arasinda yer alan netdevice katmani tarafindan yonetilmektedir. lock contention'in olusmasinin birincil sebebi, bu kuyruga alma/cikarma isleminin birim zamanda bir adet yapilmasidir. muhendislerimizden biri, bu kuyruga alma ve kuyrukktan cikarma islemlerinin toplu sekilde yapilmasini saglayan bir degisiklik yaparak, lock contention sayisinin ciddi sekilde dusmesini ve boylece 8 cekirdekli sistemlerde, 8 thread kullanabilir olmamizi sagladi.
tum bu degisiklikler, sonuc olarak memcached'in ortalama 173 microsaniye gecikme ile, saniyede 200.000 udp istemini handle edebilmesine olanak taniyor. toplam cikti 300.000 udp paketine cikabilmesine ragmen, bu sayiya ulasildiginda olusan gecikme suresi, sistemimizde kabul edemeyecegimiz kadar yuksek. yine de, eristigimiz kullanilabilir istem sayisi, default linux ve memcached'in sunabilecegi saniyede 50.000 sayisina gore oldukca iyi durumda.
yakinda, yaptigimiz bu degisiklikleri resmi memcached surumune entegre etmeyi planliyoruz, o zamana kadar bu degisikliklere github'dan ulasilabilir. -
pek bir guzel turkce bir dokumantasyonda surada vardir;
http://www.kodaman.org/…azi/memcache-veya-memcached -
ekşi sözlük kullanıcılarıyla mesajlaşmak ve yazdıkları entry'leri
takip etmek için giriş yapmalısın.
hesabın var mı? giriş yap