E-ticaret sitelerinde istenen bir olgudur yüksek trafik ama, daha da istenen satış getirecek yüksek trafiktir. Gelgelelim özellikle shared ortamlarda e-ticaret sitesi yayınlarında ve yüksek trafik düşünülmemiş kodlama yapılarında yüksek trafik ızdıraba dönüşebilir. Bu konuda düşünülmesi gereken ciddi detaylar söz konusu. E-ticaret sitelerinde yüksek trafiğe bağlı hata ve kayıpların bir kısmını trafik çok yükseldiğinde fark edebilseniz de, bazı sorunlar yüzünden trafik hiçbir zaman yükselmeyebileceğinden fark da edemeyebilirsiniz. Markafoni’nin ilk kurulduğu yıllarda, bir investment’a satılıp sonradan kapanan bir private shopping alt yapısı (besincicadde.com) sıfırdan kodlayıp çok yüksek anlık trafiklerle karşılaştığımızda aslında yüksek trafikle ilgili daha çok şeyler yapmamız gerektiği anlamıştık. Daha öncelerde de e-ticaret çalışmalarımız olmuştu ama ilk defa o zamanlar revaçta olan fırsat sitelerinden birini açmıştık ve ciddi bir duyurma ve pr ile tekil ziyaret beklentimizin çok üstünde idi. İşin zor yanı bu trafiğin çoğunun kampanya duyurusunu yaptığınız bir iki saat içine denk gelmesiydi. Sitemiz çökmemişti ama yer yer yavaşlamış ve kullanıcılardan şikayetler almıştık. İşte o günden sonra bu konuda çok ciddi bir ar-ge sürecine girdik.
Tecrübelerimizin çok detaylı olan teknik kısmına çok uzun girmeyeceğim. Ancak ulaştığımız sonuçları sizle paylaşacağım.
Sitenizin herşeyden önce BW kısıtlaması olmayan veya yüksek BW veren ve mümkünse havuz olmayan yayın ortamında tutmalısınız. En azından BW kısıtlaması olmamalı veya bu limit çok yüksek olmalı. Neden? Çünkü örneğin hostinginiz sizi X GB/ay v.b. ile kısıtlıyorsa , sizi anlık hız limiti olarak da kısıtlar ve bu limitin üstündeki ziyaretçileri reddetmeye kadar iş gidebilir. Genellikle bu tip yayınlarda size ayrılan cpu ve ram de kısıtlanacaktır. Sitenizin tüm ziyaretçileri sitenizi aynı hızda ve kesintisiz dolaşamıyor olabilir.
Güçlü Cache Yapısı olmalı. Cache çok geniş bir konu ayrı bir yazı da ayrıca değinebiliriz. Ancak çoğu sitede cache yokken, olanların çoğunda da sadece output cache var. Yani ürün ve kategori sayfaları belirli bir süre html ye çeviriliyor ve ziyaretçilere bu gösteriliyor. Bu varsa işin büyük kısmı tamam diyebilirsiniz ama öyle değil. Daha yüksek trafiklerde sepete girip anlık veritabanına bağlanmaların sayısı bile sizi terletebilir. Burada çok teknik detaya girmeden yine her biri ayrı birer yazı konusu olan sıkıştırma, nosql, sql dependency, table caching gibi pek çok cache yöntemi olduğunu ve yüksek trafikte kopma, düşme, çökme olmaması için bunları zorunlu olduğunu söylemeliyim.
Yazılımınız ve sunucunuz gzip v.b. sıkıştırma desteklemeli ve javascipt , html ve css gibi unsurları ziyaretçilere sıkıştırarak göndermelidir. Bu sayede sunucuda ilgili öğelerin sıkıştırılmış örnekleri tutulur ve siteniz çok hızlı açılır ötesinde trafik de gözle görülür biçimde düşer.
Mümkünse ve çok medyanız varsa CDN kullanın. CDN sayesinden resim video v.b. görselleri sitenizden ayrı ve dağıtık bir ortamdan ayrıca paralel olarak yükletebilirsiniz. Bu sayede medya trafiği yüzünden yazılım trafiğiniz olumsuz etkilenmez.
Yazılımınız gereksiz query ve transactionlar içermemeli , OOP alt yapısına sahip olmalı. Bu sayede her bir işlem veritabanınızı, disk, ram, nt ve cpuyu yormaz. Günümüzde open-cart, magento v.b. sistemler pek çok ihtiyaca aynı anda cevap verebilsin diye yığınla gereksiz query döndürüyor ve e-ticaret yazılımı diye bunları veya bunlardan devşirilmiş yapıları kullandığınızda, yüksek trafik eşittir yüksek sunucu ve internet alt yapısına rağmen çökme anlamına geliyor ne yazık ki.
Veritabanı mimarisi çok iyi kurgulanmış olmalı. En temelde güçlü bir indexing olmalı. Bu olmadan performanstan %80 e kadar kaybedersiniz. Querylerden alabildiğiniz kadar çoğunu store precuderlere almalısınız. Ötesinde sık kullanılrn query sonuçlarını cachelemelisiniz. Yazılım, veritabanına açtığı connectionları sadece gerekli süre kadar açık tutmalı. Burada connection pooling iyi bir seçenek. Aslında burada hız konusuna yeni başlamış oluyoruz ama bir kısmı sadece bizde mevcut olan performans odaklı bilgilerimizi anlatmaya devam edersem bu yazının sonu gelmeyecektir.
Siteniz yeterince hızlı ve yüksek trafik geldi çökmeden çok sipariş aldınız. Peki ya işin operasyonunun hızı? Burada panelinizdeki ERP de iş akışı çok iyi olmalı. Faturalar yüzlerce sipariş için aynı anda kesilebilmeli, bu sırada gönderi barkodları aynı anda yazıcılardan çıkmalı ve bu barkodları okuyan depo otomasyonu, ürünleri en kısa patikaya göre bulup işaretleyebilmeli v.b. pek çok özellik bir arada sunulabilmeli. İşte veritabanı ile çok sayıda iletişime geçilen ve yüksek miktarda veri transfer edilen böylesi bir ortamda, panelin ve sitenin veritabanlarını ayırıp aynalama (mirroring) kullanmaya kadar işi götürmek gerekebilir. Zira sitenize günde yüz binlerce kişi girip binlerce sipariş verirken aynı anda panelden bu siparişlerin fatura, üretim, depo hareketlerini yönetmek de sitenizi yavaşlatabilecektir.
Çok yüksek trafik alıp bunun için sevinebildiğiniz bir alt yapı için biz yazılım ve yayın alt yapımızla hazırız.
www.ikost.com
