E-ticarette sunucu performansı doğrudan gelir kalemidir. Sepet sayfası yavaş açılan bir sitede terk oranı yükselir; kampanya saatinde çöken bir sitede o günün cirosu tamamen kaybedilir. Bu yüzden bir e-ticaret projesi için VDS sunucu seçimi ve yapılandırması, teknik bir detay değil ticari bir karardır.
Bu rehber, e-ticaretin sunucudan ne istediğini, normal günle kampanya günü arasındaki farkı ve yoğun trafiğe hazırlığın nasıl yapıldığını anlatıyor.
E-ticaret Neden Diğer Sitelerden Farklı Yüklenir?
Bir blog veya kurumsal site, aynı içeriği herkese gösterir — dolayısıyla neredeyse tamamen önbelleğe alınabilir. E-ticaret sitesinde ise durum farklıdır:
- Kişiye özel sayfalar önbelleğe alınamaz: Sepet, hesabım, sipariş geçmişi ve fiyat gösterimi kullanıcıya göre değişir. Bu sayfalar her istekte veritabanına gider.
- Yazma trafiği yüksektir: Her sepete ekleme, her stok güncellemesi, her sipariş bir yazma işlemidir. Blogda okuma baskındır; e-ticarette yazma payı belirgindir ve yazma işlemleri önbelleğe alınamaz.
- Oturum yönetimi süreklidir: Binlerce eşzamanlı oturum, bellek ve depolama tarafında sürekli bir yük oluşturur.
- Trafik son derece dalgalıdır: Normal günün on katı trafik, kampanya duyurusundan sonraki ilk on dakikada gelebilir. Ortalama trafik için boyutlandırılmış bir sunucu o anda çöker.
- Kesinti tolere edilemez: Blogda beş dakikalık kesinti fark edilmez; ödeme adımında beş dakikalık kesinti, o anki tüm sepetlerin kaybı demektir.
Boyutlandırma: Ortalamaya Değil Tepeye Göre
E-ticaret sunucusu boyutlandırmasında en yaygın hata, aylık ortalama trafiğe göre karar vermektir. Doğru referans, yılın en yoğun saatidir.
Pratik bir yaklaşım şudur: geçen yılın en yoğun gününde aldığınız eşzamanlı ziyaretçi sayısını bulun, büyüme oranınızla çarpın ve bunun üzerine güvenlik payı ekleyin. Bu sayı, sunucunuzun karşılaması gereken tepe yüktür. Kaynakların size özel ayrıldığı bir VDS yapısında bu hesap anlamlıdır; paylaşımlı bir ortamda ise tepe yükü karşılayacağınızın garantisi yoktur çünkü kaynaklar komşularla paylaşılır.
Kaynak Önceliklendirmesi
| Kaynak | E-ticaret için önemi | Neden |
|---|---|---|
| Disk hızı (NVMe) | Kritik | Yazma yoğun iş yükü; sipariş ve stok işlemleri diske gider |
| RAM | Kritik | Veritabanı bellek havuzu + oturumlar + eşzamanlı işçiler |
| CPU | Yüksek | Önbelleğe alınamayan dinamik sayfa üretimi |
| Bant genişliği | Orta | Ürün görselleri ağırdır ama dağıtım ağına taşınabilir |
Yapılandırma: Yoğun Trafiğe Dayanan Kurulum
1. Önbelleği Katmanlı Kurun
E-ticarette tek bir önbellek çözümü yetmez. Üç katman gerekir: statik dosyalar için tarayıcı ve dağıtım ağı önbelleği, kategori ve ürün listeleme sayfaları için sayfa önbelleği, veritabanı sorguları için nesne önbelleği. Sepet ve ödeme adımlarını mutlaka önbellek dışında bırakın — burada yapılan bir hata, kullanıcıya başka birinin sepetini göstermek gibi ciddi sonuçlar doğurur.
2. Veritabanını E-ticaret İçin Ayarlayın
Varsayılan veritabanı yapılandırması e-ticaret iş yükü için tasarlanmamıştır. İki ayar öne çıkar: bellek havuzunu sunucunun gerçek RAM'ine göre büyütmek ve yazma işlemlerinin diske aktarım davranışını iş yükünüze göre ayarlamak. İkinci ayarda dikkatli olun — dayanıklılık ile hız arasında bir denge kurar ve sipariş verisinde dayanıklılık önceliklidir.
3. Oturumları Bellekte Tutun
Oturum verilerinin dosya sisteminde tutulması, yoğun trafikte disk üzerinde binlerce küçük dosya okuma/yazma işlemi üretir. Oturumları bellek tabanlı bir depoya taşımak, kampanya saatlerinde en çok fark yaratan optimizasyonlardan biridir.
4. Ürün Görsellerini Disipline Edin
E-ticaret sitelerinde sayfa ağırlığının büyük bölümü ürün görselleridir. Üç kural: modern görüntü biçimleri kullanın, her kullanım yerine uygun boyutta sürüm üretin (liste sayfasında tam boyutlu görsel sunmayın) ve ekranda görünmeyenleri geciktirmeli yükleyin. Bunları yapmak sunucu yükünü ve bant genişliğini aynı anda düşürür.
5. Ağır İşleri Arka Plana Taşıyın
Sipariş sonrası e-posta gönderimi, fatura üretimi, muhasebe entegrasyonu ve stok senkronizasyonu gibi işleri kullanıcının isteği içinde çalıştırmayın. Bunları bir kuyruğa alıp arka planda işleyin. Aksi halde ödeme adımının süresi, bir dış servisin yanıt süresine bağlı hale gelir — ve o servis yavaşladığında ödeme sayfanız yavaşlar.
Kampanya Öncesi Kontrol Listesi
Büyük bir kampanyadan önce yapılacaklar, o gün sabahı yapılamaz. Aşağıdaki liste kampanyadan en az bir hafta önce tamamlanmalıdır:
- Yük testi yapın: Beklediğiniz tepe trafiğin altında değil, üstünde bir yükle test edin. Testi canlı ortamın kopyası bir ortamda yapın ve nerede kırıldığını bulun.
- Kaynakları geçici olarak artırın: Kampanya dönemi için kapasite artırımı yapın, sonrasında geri düşürün. Kalıcı büyütmeye göre çok daha ekonomiktir.
- Kod dondurun: Kampanyadan birkaç gün önce yeni sürüm çıkmayı bırakın. Yoğun trafikte hata ayıklamak, normal günde ayıklamaktan kat kat zordur.
- Yedeği doğrulayın: Kampanya öncesi tam yedek alın ve geri yüklenebildiğini test edin. En kötü senaryoda geri dönüş noktanız olsun.
- İzlemeyi sıkılaştırın: Uyarı eşiklerini kampanya dönemi için düşürün ve uyarıların kime gideceğini netleştirin. O gün kimin nöbetçi olduğu belli olmalı.
- Ödeme sağlayıcınızı bilgilendirin: Beklenen işlem hacmini önceden bildirin. Ani hacim artışları bazı sağlayıcılarda güvenlik kontrolü tetikler.
- Geri çekilme planı hazırlayın: Site dayanamazsa ne yapacaksınız? Bakım sayfası, kuyruk sistemi veya kampanyayı kademeli açmak — kararı önceden verin.
Kampanya Sırasında Neye Bakılır?
Kampanya saatinde teknik ekibin izleyeceği metrikler, normal günden farklıdır. Öncelik sırası şudur: ödeme adımının başarı oranı, sepet sayfasının yanıt süresi, veritabanı bağlantı havuzu doluluğu ve hata log yoğunluğu. Sunucu kaynak metrikleri (CPU, RAM) bunların nedenini açıklar ama karar, kullanıcı deneyimi metriklerine göre alınır.
Bir metrik özellikle önemlidir: terk edilen sepet oranındaki ani artış. Bu, teknik metrikler henüz kritik görünmezken bile kullanıcıların sorun yaşadığını haber verir.
Sonuç
E-ticaret için sunucu hazırlığı, kampanya sabahı yapılan bir iş değildir. Doğru boyutlandırılmış ve katmanlı önbelleğe sahip bir VDS sunucu, aynı donanımla yapılandırılmamış bir sunucudan kat kat fazla eşzamanlı kullanıcı taşır. Ölçüt basit: yük testinde kırılma noktanızı biliyor musunuz? Cevap hayırsa, kampanya günü o noktayı müşterilerinizle birlikte öğreneceksiniz.
Sıkça Sorulan Sorular (SSS)
VDS sunucum kaç eşzamanlı ziyaretçi taşır?
Donanımdan bağımsız tek bir sayı verilemez; belirleyici olan yapılandırmadır. Aynı donanım, önbelleksiz bir kurulumda birkaç yüz, katmanlı önbellekli bir kurulumda binlerce eşzamanlı ziyaretçi taşıyabilir. Kendi sayınızı öğrenmenin tek yolu yük testidir.
E-ticaret için dağıtım ağı (CDN) şart mı?
Şart değil ama getirisi yüksektir. Ürün görselleri toplam trafiğin büyük bölümünü oluşturur; bunları dağıtım ağına devretmek sunucunuzun bant genişliğini ve istek yükünü belirgin biçimde azaltır. Dinamik sayfa üretimi yine sizin sunucunuzda kalır.
Kampanya için kalıcı büyütme mi, geçici artırım mı?
Yıl boyunca sürekli yüksek trafiğiniz varsa kalıcı; trafik yalnızca belirli dönemlerde sıçrıyorsa geçici artırım. Yılda dört kampanya için yıl boyu üç kat kapasite ödemek, bütçenin büyük bölümünü boşta duran kaynağa harcamak demektir.
Ödeme verilerini sunucumda tutabilir miyim?
Kart verisini kendi sunucunuzda saklamak, ağır uyum yükümlülükleri getirir ve önerilmez. Ödeme sağlayıcısının barındırdığı akışları kullanmak hem uyum riskini hem güvenlik yükünü sağlayıcıya devreder. Sunucunuzda yalnızca işlem referansı ve sipariş verisi kalmalıdır.
