E-Ticaret Sitesi İçin Hangi Hosting Gerekir?

E-ticaret hosting seçimi, vitrin sitesi için hosting seçmeye hiç benzemez ve bu farkı en acı şekilde öğrenme yeri genellikle kampanya günüdür. Sabah kampanya duyurusu gider, trafik on katına çıkar, ana sayfa hâlâ açılır ama sepet sayfası dönmeye başlar, ödeme adımında müşteriler "işlem tamamlanamadı" görür ve akşama kadar kaç sipariş kaybedildiği asla tam olarak bilinemez. Oysa bu tabloyu üreten şey ne trafiğin büyüklüğüdür ne de sunucunun "yavaş" olmasıdır: e-ticaret sitelerinde çöken şey her zaman aynı, çok dar bir yerdir.

Bu yazıda online mağaza hostingini pazarlama diliyle değil, gerçek kaynak matematiğiyle ele alacağız. Ürün sayısıyla veritabanı yükünün nasıl ilişkilendiğini, eşzamanlı ziyaretçiden PHP işçi sayısının nasıl hesaplandığını, kampanya günü çöken sitelerin tam olarak neden çöktüğünü, sanal POS ve 3D Secure akışının hostingden ne beklediğini ve WooCommerce, OpenCart, PrestaShop gibi altyapıların birbirinden ayrıldığı noktaları göreceksiniz. Sonunda elinizde, kendi mağazanızın rakamlarını yerine koyup karar verebileceğiniz bir çerçeve olacak.

E-Ticaret Sitesini Vitrin Sitesinden Ayıran Dört Şey#

E-ticaret sitesinin hosting ihtiyacını büyüten şey ziyaretçi sayısı değil, isteklerin önbelleğe alınamamasıdır. Kurumsal bir tanıtım sitesinde ziyaretçilerin neredeyse tamamı aynı sayfayı görür, dolayısıyla tam sayfa önbelleği devreye girer ve PHP hiç çalışmaz. Mağazada durum tersine döner:

1. Sepet ve ödeme sayfaları önbelleğe alınamaz. Her ziyaretçinin sepeti farklıdır. WooCommerce'te bu sayfalar DONOTCACHEPAGE sabitiyle işaretlenir, OpenCart ve PrestaShop'ta da oturum bazlı çalışır. Bu sayfalar her açılışta veritabanına gider.
2. Oturum (session) yazımı sürekli disk/veritabanı işlemi üretir. Sepete bir ürün eklendiği anda bir kayıt yazılır. 500 kişi aynı anda geziniyorsa 500 oturum canlıdır.
3. Arama ve filtreleme ağırdır. "1.500-2.000 TL arası, mavi, stokta olan" filtresi, indeks yoksa on binlerce satır tarar ve önbellekten servis edilemez.
4. Yazma yükü vardır. Sipariş, stok düşümü, kupon kullanımı, e-posta kuyruğu — hepsi yazma işlemidir ve okuma önbelleği bunları hızlandırmaz.

Bu dört madde, e-ticaret hostingde tek bir sonuca çıkar: belirleyici kaynak, aynı anda kaç PHP isteğinin işlenebildiğidir. Disk alanı, bant genişliği ve "sınırsız" ifadeleri bu sorunun cevabı değildir.

Ürün Sayısı ve Ziyaretçiden Kaynak İhtiyacını Hesaplama#

Türkçe kaynaklarda en çok eksik olan kısım budur: rakamları birbirine bağlayan formül. İki basit hesapla ihtiyacınızı çıkarabilirsiniz.

1. Eşzamanlı istek (PHP işçi ihtiyacı). Little yasasının basit hâli:

Gereken PHP işçisi ≈ (Saniyedeki dinamik istek) × (Ortalama istek süresi, saniye)

Örnek: Kampanya saatinde dakikada 1.200 dinamik sayfa görüntüleniyor, yani saniyede 20 istek. Ortalama sunucu işleme süresi 0,4 saniye. İhtiyaç: 20 × 0,4 = 8 eşzamanlı PHP işçisi. Ama sipariş yoğunluğunda ortalama süre 1,2 saniyeye çıkarsa aynı trafik 24 işçi ister. Süre üç katına çıktığında ihtiyacın da üç katına çıkması, kampanya çöküşlerinin asıl mekanizmasıdır.

2. Veritabanı büyüklüğü. Ürün sayısı doğrudan satır sayısına dönüşmez; asıl çarpan varyasyon ve nitelik sayısıdır. WooCommerce'te kabaca:

postmeta satırı ≈ Ürün sayısı × (20-40) + Varyasyon sayısı × (15-25)

2.000 ürünü olan, her üründe ortalama 4 varyasyon bulunan bir mağazada bu, yüz binlerce satır anlamına gelir. Bu sayı tek başına sorun değildir; sorun, bu tablonun indekssiz sorgularla taranmasıdır.

Aşağıdaki tablo, sahada gördüğüm tipik eşleşmeleri özetler:

Tabloyu okurken "günlük ziyaretçi" değil, zirve eşzamanlı sütununa bakın. Aynı günlük ziyaretçiyi 24 saate yayan bir mağaza ile akşam 20.00-22.00 arasına sıkıştıran bir mağaza tamamen farklı altyapı ister. Ziyaretçi-paket ilişkisinin genel çerçevesini kaç ziyaretçi için hangi hosting paketi yazısında ayrıca ele aldık.

Kampanya Günü Siteler Neden Çöker#

Kampanya çöküşü kademeli değil, aniden gerçekleşir ve sebebi neredeyse her zaman kuyruk birikmesidir. Mekanizma şudur:

1. Trafik artar, PHP işçilerinin hepsi dolar.
2. Yeni istekler kuyruğa girer; kuyruk uzadıkça bekleme süresi artar.
3. Bekleyen istekler zaman aşımına uğrar ve kullanıcı sayfayı yeniler.
4. Yenileme yeni istek üretir — kuyruk artık trafikten daha hızlı büyür.
5. Sunucu, tamamlanmayacak istekleri işlemekle meşgul olur; başarılı sipariş sayısı sıfıra yaklaşır.

Ziyaretçinin gördüğü şey 502, 503 veya 504 hatasıdır ve bu üç kod farklı katmanları işaret eder: 503 sunucunun isteği kabul edecek kapasitesi kalmadığını, 504 ise arka uçtan cevabın zamanında gelmediğini gösterir.

Kampanya öncesi bu zinciri kıran dört önlem:

• Statik sayfalarda tam sayfa önbelleği, sepet/ödeme/hesap sayfalarında istisna. Bu istisna kuralları yanlış yazılırsa müşteri başkasının sepetini görür; kural yazımını mutlaka test edin.
• Object cache açın. Ürün listeleme ve kategori sorgularının sonucu bellekte tutulursa veritabanı yükü belirgin biçimde düşer. Kurulum için Redis object cache yazısı adım adım yol gösterir.
• Sepet parçacığı (cart fragment) isteklerini sınırlayın. WooCommerce'te her sayfa yüklemesinde ?wc-ajax=get_refreshed_fragments çağrısı yapılır. Kampanyada bu çağrı, sayfa isteklerinin bir katı kadar ek yük demektir.
• Zamanlanmış görevleri kampanya saatinden kaydırın. Yedekleme, ürün besleme (feed) güncellemesi, XML aktarımı ve e-posta kuyruğu aynı saatte çalışıyorsa kapasitenizin bir kısmını zaten harcamışsınız demektir.

Kampanya öncesi gerçek yükü ölçmek için basit bir test yeterlidir:

# Ana sayfa ve ürün sayfasında sunucu işleme süresi
curl -o /dev/null -s -w "baglanti:%{time_connect}s ilk_bayt:%{time_starttransfer}s toplam:%{time_total}s\n" https://magazaniz.com/urun/ornek-urun/

# Ödeme sayfasında (önbelleksiz gerçek maliyet)
curl -o /dev/null -s -w "ilk_bayt:%{time_starttransfer}s\n" https://magazaniz.com/odeme/

Ödeme sayfasındaki ilk bayt süresi 1 saniyeyi aşıyorsa, kampanya trafiği bu süreyi katlayarak büyütecektir.

Veritabanı: E-Ticarette Asıl Darboğazın Bulunduğu Yer#

E-ticaret sitelerinde performans sorunlarının çoğu sunucunun CPU'sunda değil, veritabanı sorgularında yaşanır. Kontrol edilecek dört yer:

1. Otomatik yüklenen ayar verisi. WordPress tabanlı mağazalarda her istekte wp_options tablosundan otomatik yüklenen veri okunur:

SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options WHERE autoload = 'yes';

1 MB üstü değer, her sayfa yüklemesine ölçülebilir bir gecikme ekler.

2. Şişen oturum ve geçici veri tabloları. Terk edilmiş sepetler ve süresi geçmiş oturumlar birikir:

-- WooCommerce oturum sayısı
SELECT COUNT(*) FROM wp_woocommerce_sessions;

-- En büyük tablolar
SELECT table_name, ROUND(((data_length + index_length)/1024/1024),1) AS mb
FROM information_schema.TABLES WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC LIMIT 10;

3. Zamanlanmış görev kuyruğu. Action Scheduler tablosu on binlerce tamamlanmış kayıtla dolduğunda her sayfa yüklemesi yavaşlar.

4. Eksik indeksler. Yavaş sorgu kaydını açıp gerçekten hangi sorgunun yavaş olduğunu görmeden indeks eklemeyin:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

Veritabanı tarafında yapılabilecek ayarların tamamını MySQL/MariaDB performans optimizasyonu yazısında topladık.

Disk Tipi, SSL ve Ödeme Altyapısının Gerçek Gereksinimleri#

Disk tipi. E-ticarette disk performansı, dosya boyutundan çok küçük rastgele okuma-yazma sayısıyla (IOPS) ilgilidir. Sipariş yazımı, oturum güncellemesi ve önbellek dosyaları hep küçük işlemlerdir. NVMe ile SATA SSD arasındaki farkın hangi iş yükünde hissedildiğini SSD mi NVMe mi hosting yazısında karşılaştırdık; özet olarak e-ticaret, farkın en net görüldüğü yüklerden biridir.

SSL. Ödeme alan bir sitede SSL tartışma konusu değildir, ama seçim şu üç noktada netleşmelidir:

• Sertifika tipi: Alan adı doğrulamalı (DV) sertifika ödeme almak için teknik olarak yeterlidir; kurumsal (OV/EV) sertifikalar ise şirket kimliğinin de doğrulandığını belgeler.
• Otomatik yenileme: Sertifikanın süresi kampanya gecesi dolarsa site tamamen erişilemez hâle gelir. Yenilemeyi otomatiğe bağlayın.
• Karışık içerik: Sitede http:// ile çağrılan tek bir görsel bile tarayıcıda kilit simgesini kırar ve dönüşüm oranını düşürür.

Sanal POS ve 3D Secure. Ödeme sağlayıcısıyla hostingin kesiştiği noktalar çoğu rehberde hiç yer almaz, oysa siparişlerin sessizce kaybolduğu yer tam burasıdır:

• Dönüş (callback) adresi erişilebilir olmalı. Banka, ödeme sonucunu sitenize bir istekle bildirir. Güvenlik duvarı ya da WAF kuralı bu isteği engelliyorsa para çekilir ama sipariş oluşmaz. Bu, sahada gördüğüm en sinsi hatadır.
• Sunucu saati doğru olmalı. İmza ve zaman damgası doğrulamaları saat kaymasında başarısız olur. timedatectl ile NTP eşlemesini doğrulayın.
• Giden bağlantıya izin verilmeli. Bazı entegrasyonlar sunucudan bankaya giden istek atar; giden trafiğin kapalı olduğu yapılandırmalarda ödeme adımı zaman aşımına uğrar.
• TLS sürümü güncel olmalı. Ödeme sağlayıcıları eski TLS sürümlerini kabul etmez.

Sanal POS başvuru sürecinin ticari tarafını sanal POS nedir, nasıl alınır yazısında ele aldık.

Altyapıya Göre Farklar: WooCommerce, OpenCart, PrestaShop#

Üç altyapı da PHP ve MySQL kullanır ama kaynak profilleri farklıdır:

Ortak PHP gereksinimleri de vardır ve paylaşımlı pakette eksik kalabilir: intl, mbstring, bcmath, soap, curl, zip, gd veya imagick. Sanal POS entegrasyonlarının çoğu soap ve curl ister; hangi eklentiyi neden açacağınızı cPanel PHP eklenti seçimi yazısında listeledik.

PHP ayarlarında e-ticaret için tipik hedefler:

memory_limit = 512M
max_execution_time = 120
max_input_vars = 5000
post_max_size = 64M
upload_max_filesize = 64M

max_input_vars değeri özellikle önemlidir: çok varyasyonlu bir ürünü kaydederken bu limit dolduğunda form sessizce kırpılır ve varyasyonların bir kısmı kaybolur — hata mesajı da görmezsiniz.

Yedekleme, Ölçek Kararı ve Kontrol Listesi#

Yedekleme e-ticarette diğer sitelerden farklıdır, çünkü kaybedilen veri metin değil siparıştır. Üç kural:

1. Sıklık, sipariş hacminize göre belirlenir. Günde 5 sipariş alan bir mağaza için günlük yedek yeterlidir; saatte 20 sipariş alan bir mağazada günlük yedek, en kötü senaryoda bir günlük siparişi silmek demektir.
2. Yedek başka bir yerde durmalı. Sunucunun kendi diskindeki yedek, disk arızasında yoktur.
3. Geri dönüş denenmemiş yedek, yedek değildir. Yılda en az bir kez test ortamına geri yükleyin.

Paylaşımlı hostingten sunucuya geçiş kararı şu üç sinyalden biri ortaya çıktığında verilir: (a) zirve saatlerde düzenli olarak kaynak limiti ihlali görüyorsunuz, (b) ödeme entegrasyonu için gereken PHP eklentisi ya da giden bağlantı izni pakette yok, (c) ürün sayınız ve veritabanı boyutunuz tabloda VDS satırına geçmiş durumda. Yükseltme kararını eşiklerle vermek için hosting paketi yükseltme zamanı yazısındaki ölçüm tablosunu kullanabilirsiniz. Kampanya öncesi trafik ve transfer tahmini için bant genişliği hesaplayıcısını kullanabilirsiniz.

Sipariş öncesi kontrol listesi:

• Ödeme sayfasının önbelleksiz ilk bayt süresi ölçüldü mü
• PHP sürümü ve gerekli eklentiler (soap, curl, intl, bcmath) açık mı
• max_input_vars ve memory_limit yeterli mi
• Object cache (Redis/Memcached) kullanılabiliyor mu
• SSL otomatik yenilemede mi
• Giden bağlantı ve banka dönüş adresi engelli mi
• Yedek sıklığı sipariş hacmine uygun ve dışarıda mı tutuluyor
• Zamanlanmış görevler kampanya saatlerinin dışına alındı mı
• Kaynak limiti ihlali (fault) geçmişi temiz mi

Sıkça Sorulan Sorular#

E-ticaret sitesi için paylaşımlı hosting yeterli olur mu#

Evet, ürün sayısı birkaç yüzü ve zirve eşzamanlı ziyaretçi onu geçmeyen mağazalarda paylaşımlı hosting fazlasıyla yeterlidir. Belirleyici olan toplam ziyaretçi değil, aynı anda kaç kişinin sepet ve ödeme gibi önbelleğe alınamayan sayfalarda olduğudur. Ürün ve varyasyon sayısı arttıkça veritabanı sorguları ağırlaşır ve object cache ile sunucu tarafı ayar imkânı gerekmeye başlar. Zirve saatlerde düzenli kaynak limiti ihlali görüyorsanız, artık paylaşımlı paketin sınırındasınız demektir.

E-ticaret için ne kadar disk alanı gerekir#

Disk alanı e-ticarette nadiren sınırlayıcı unsurdur; asıl belirleyici, ürün görsellerinin boyutu ve yedeklerin nerede tutulduğudur. Bin ürünlü tipik bir mağazada görseller optimize edilmişse birkaç GB'lık alan uzun süre yeterli olur. Alanı asıl dolduran şeyler genellikle sıkıştırılmamış orijinal görseller, sunucu üzerinde biriken eski yedekler ve temizlenmemiş log dosyalarıdır. Alan planlarken toplam boyuttan çok, dosya sayısı limitine (inode) dikkat edin; çok sayıda küçük önbellek dosyası bu limiti diskten önce doldurur.

Kampanya günü sitem çökmesin diye ne yapmalıyım#

En etkili önlem, kampanya öncesi ödeme ve sepet sayfalarının önbelleksiz süresini ölçüp bu süreyi kısaltmaktır. Statik sayfalarda tam sayfa önbelleğini açın, sepet ve ödeme sayfalarını istisna tutun, object cache'i devreye alın ve zamanlanmış görevleri kampanya saatinin dışına taşıyın. Kampanyadan en az bir hafta önce kapasiteyi artırın; kampanya sabahı yapılan değişiklik sorunu çözmek yerine yeni değişken ekler. Ayrıca sepet parçacığı isteklerinin sayfa başına kaç ek istek ürettiğini kontrol edin, çünkü yoğun trafikte bu çağrılar yükü sessizce ikiye katlar.

Sanal POS için hosting tarafında özel bir şey gerekir mi#

Evet, sanal POS entegrasyonu hostingden üç şey bekler: bankanın gönderdiği dönüş isteğinin sunucuya ulaşabilmesi, sunucudan bankaya giden bağlantıya izin verilmesi ve sunucu saatinin doğru olması. Güvenlik duvarı veya WAF kuralı bankanın dönüş isteğini engellediğinde para çekilir ama sipariş oluşmaz; bu, en zor fark edilen hatadır çünkü site tamamen normal görünür. Ayrıca entegrasyonların çoğu soap ve curl PHP eklentilerine ihtiyaç duyar. Güncel TLS sürümünün desteklendiğinden de emin olun, eski sürümler ödeme sağlayıcıları tarafından reddedilir.

WooCommerce mi OpenCart mı daha az kaynak tüketir#

Kaynak tüketimini altyapının kendisi değil, üzerine kurulan eklenti ve tema seti belirler. Sade kurulumda OpenCart görece daha ılımlı davranır, ancak yirmi eklenti yüklenmiş bir OpenCart, iyi optimize edilmiş bir WooCommerce'ten çok daha ağır çalışabilir. WooCommerce'in meta tablo ağırlıklı yapısı ürün sayısı büyüdükçe daha fazla satır üretir, buna karşılık ekosistemi sayesinde önbellekleme çözümleri daha olgundur. Karar verirken tüketimden çok, ekibinizin hangi altyapıyı sürdürebileceğine bakın.

Online mağaza için yedekleme ne sıklıkla alınmalı#

Yedekleme sıklığı sipariş hacmine göre belirlenir; kayıp göze alınabilecek en uzun süre neyse, yedek aralığı o kadar olmalıdır. Günde birkaç sipariş alan bir mağaza için günlük yedek makuldür, saatte onlarca sipariş alan bir mağazada günlük yedek bir günlük satışı silmek anlamına gelir. Yedeklerin sunucudan ayrı bir yerde tutulması ve en az yılda bir kez geri yükleme denemesi yapılması şarttır. Kampanya dönemlerinde ise kampanya başlamadan hemen önce ek bir tam yedek alın.

E-ticaret sitem yavaşsa önce neye bakmalıyım#

Önce ana sayfa ile ödeme sayfasının sunucu tarafı sürelerini ayrı ayrı ölçün, çünkü ikisi farklı sorunları işaret eder. Ana sayfa hızlı, ödeme sayfası yavaşsa sorun önbellekte değil veritabanı ve PHP tarafındadır; her ikisi de yavaşsa sunucu kaynakları ya da önbellek yapılandırması sorgulanmalıdır. Veritabanı tarafında bakılacak ilk yerler otomatik yüklenen ayar verisinin boyutu, şişen oturum tabloları ve tamamlanmış zamanlanmış görev kayıtlarıdır. Bunlar temizlendikten sonra hâlâ yavaşsa yavaş sorgu kaydını açıp gerçekten hangi sorgunun süre tükettiğini görmeniz gerekir.

Kapanış#

E-ticaret hosting seçiminin özeti tek cümleyle şudur: mağazanızın hostingden istediği şey alan değil, aynı anda işlenebilen dinamik istek sayısıdır. Sepet ve ödeme sayfaları önbelleğe alınamadığı için kaynak ihtiyacınız ziyaretçi sayısıyla değil, zirve eşzamanlı kullanıcı ve ortalama işlem süresiyle büyür; kampanya günü çöküşleri de tam olarak bu iki değerin çarpımı kapasiteyi aştığında başlar. Ürün ve varyasyon sayısı veritabanı yükünü, sanal POS entegrasyonu ise güvenlik duvarı ve giden bağlantı yapılandırmasını belirler. Bu dört değişkeni ölçtüğünüzde hangi ölçekte altyapıya ihtiyacınız olduğu tartışma konusu olmaktan çıkar.

Mağazanız için hazır yapılandırılmış bir başlangıç arıyorsanız e-ticaret hosting paketleri gerekli PHP eklentileri ve kaynak profiliyle bu iş için hazırlanmıştır; ürün sayınız ve trafiğiniz tablodaki üst basamaklara geçtiyse kaynakların tamamen size ayrıldığı sanal sunucu tarafı doğru adrestir. Ödeme alan her sitede zorunlu olan sertifikayı SSL sayfasından alabilir, sipariş verisini kaybetmemek için düzenli ve sunucu dışında saklanan yedekleme hizmetini devreye alabilirsiniz. Mevcut mağazanızı taşımak istiyorsanız veri ve sipariş geçmişinin eksiksiz aktarımı için site taşıma hizmeti bu işi üstlenir.