Çoğu kişi sunucu seçimini bir fiyat karşılaştırması sanır. "Aylık şu kadara sınırsız hosting var, script de PHP çalışıyor, olur biter" der. Oysa dijital ürün satış scripti sıradan bir tanıtım sitesi değildir; içinde stok kilitleri, eşzamanlı sipariş yazımı, kod teslim kuyruğu ve ödeme bildirimi işleyen bir işlem motoru vardır. Bu motorun davranışı sunucunun CPU'suna değil, çoğu zaman disk gecikmesine ve veritabanı ayarlarına bağlıdır.
Hosting firmalarının pazarlama sayfalarında bu detaylar geçmez, çünkü satılan şey kaynak değil vaattir. Gerçek şu: doğru yapılandırılmış 2 çekirdek ve 4 GB bellek, yanlış yapılandırılmış 8 çekirdekten daha iyi performans verir. Bu yazıda e-pin satış yazılımı için PHP ve MySQL tarafında neyin gerçekten fark yarattığını, kaynakları ciroya göre nasıl planlayacağını ve kampanya anında neyin çöktüğünü tek tek açacağız.
Çoğu Kişi "Paylaşımlı Hosting Yeter" Sanır Ama Hangi Duvara Çarpar?
Paylaşımlı hosting gerçekten yeterlidir; günlük 30-50 sipariş bandına kadar. Duvar CPU'da değil, eşzamanlı süreç limitinde ve inode/dosya işlemi kotasında çıkar. Paylaşımlı planlarda genelde 20-30 eşzamanlı PHP süreci sınırı vardır. Normal günde sorun yok; bir kampanya duyurusundan sonra aynı anda 80 kişi ödeme sayfasına girdiğinde sunucu yeni istekleri sıraya alır, ödeme sağlayıcısının bildirimi zaman aşımına düşer ve sen "para geldi ama sipariş beklemede" tablosuyla uğraşırsın.
İkinci duvar cron tarafında. E-pin işinde tedarikçi stok senkronizasyonu, kod havuzu kontrolü ve bekleyen teslimat kuyruğu dakikalık cron ister. Birçok paylaşımlı plan cron'u 5 veya 15 dakikadan sık çalıştırmaz. Bu da otomatik teslimatın gecikmesi demektir; müşteri açısından fark "anında" ile "on beş dakika" arasındaki fark kadar büyüktür.
PHP Sürümü Neden Sandığından Daha Kritik?
PHP 7.4 ile PHP 8.3 arasındaki fark sadece hız değil, bellek davranışı. Aynı işlemi 8.x sürümleri belirgin şekilde daha az bellekle tamamlar; bu da aynı RAM'de daha fazla eşzamanlı istek demek. Ama asıl mesele destek: güncel bir epin yazılım paketi modern PHP'nin tip kontrolleri ve şifreleme fonksiyonlarını kullanır. Eski sürümde çalıştırmaya zorlarsan ya kurulum patlar ya da güvenlik katmanı sessizce devre dışı kalır.
Yapılandırma tarafında üç ayarı mutlaka kontrol et: OPcache açık ve yeterli bellek ayrılmış olmalı, max_execution_time stok senkronizasyonunu boğmayacak kadar uzun olmalı, memory_limit 256 MB altına düşmemeli. Gerekli PHP eklentileri de sabittir: PDO, mbstring, curl, openssl, json, zip, gd veya imagick, intl. Bunlardan biri kapalıysa kurulum adımında değil, ilk ödeme denemesinde hata alırsın.
| Günlük Sipariş | Önerilen Kaynak | Barındırma Tipi | MySQL Buffer Pool | Yedekleme Sıklığı |
|---|---|---|---|---|
| 0 - 50 | 1 vCPU / 2 GB | Kaliteli paylaşımlı veya küçük VPS | 256 - 512 MB | Günlük |
| 50 - 200 | 2 vCPU / 4 GB | VPS (NVMe disk) | 1 GB | Günlük + haftalık arşiv |
| 200 - 600 | 4 vCPU / 8 GB | VPS / bulut sunucu | 2 - 3 GB | Günde 2 kez |
| 600 - 2.000 | 6 - 8 vCPU / 16 GB | Ayrı veritabanı sunucusu | 6 - 8 GB | Saatlik artımlı |
| 2.000 üzeri | 8+ vCPU / 32 GB | Yük dengeli çoklu uygulama sunucusu | 16 GB+ | Sürekli replikasyon |
MySQL Tarafında Seni Bekleyen Gerçek Darboğaz Ne?
Cevap neredeyse her zaman aynı: InnoDB buffer pool'un küçük olması. Veritabanının sık kullanılan bölümü belleğe sığmıyorsa her sorgu diske iner. Diske inen sorgu, bellekten okunan sorgudan onlarca kat yavaştır. Sipariş tablosu birkaç yüz bin satıra ulaştığında bu fark listeleme ekranlarında saniyelerle ölçülmeye başlar.
İkinci darboğaz kilitlenme. E-pin satışının kalbi "aynı kodu iki kişiye satmamak"; bu da stok satırının işlem sırasında kilitlenmesi anlamına gelir. Motor bu kilidi doğru kurmuyorsa ya çift satış olur ya da yoğunlukta kilit bekleme zaman aşımı hatası patlar. Bu yüzden veritabanı motorunun InnoDB olması ve tabloların doğru indekslenmesi tercih değil zorunluluktur. Pinova'nın sipariş ve stok mimarisi bu kilit davranışını esas alarak kurulmuştur; ayrıntıları özellikler sayfasında bulabilirsin.
Yavaş Çalışan E-pin Kurulumlarında Gecikmenin Kaynağı
- Veritabanı sorguları ve indeks eksikliği 42%
- Önbellek kapalı / OPcache yok 28%
- Yavaş disk ve yetersiz RAM 18%
- Dış servis çağrıları ve ağ 12%
RAM ve CPU'yu Ciroya Göre Nasıl Planlarsın?
Basit bir kural işine yarar: CPU eşzamanlı isteği, RAM eşzamanlı kullanıcıyı kaldırır. E-pin sitelerinde trafik hafif ama işlem yoğundur; yani çoğunlukla RAM'e ihtiyacın olur. 4 GB bellekte PHP süreçleri için yaklaşık 1,5 GB, MySQL için 1,5 GB, sistem ve web sunucusu için 1 GB ayırmak dengeli bir dağılımdır.
Disk tarafında tek bir tavsiye var: NVMe. Klasik SSD bile sipariş yazma gecikmesini iki katına çıkarabilir. Ayrıca disk boyutunu ürün sayısına göre değil log ve yedek boyutuna göre planla. Aktif bir kurulumda işlem log'ları, cron çıktıları ve veritabanı yedekleri aylar içinde ürün dosyalarından daha fazla yer tutar.
Sunucuyu satın almadan önce sağlayıcıdan disk yazma hızı ve eşzamanlı PHP süreç limiti değerlerini yazılı olarak iste. Bu iki sayıyı vermeyen bir sağlayıcı, yoğun saatte seni yalnız bırakacak sağlayıcıdır.
Kampanya Anında Sunucun Neden Çöker?
Çökmenin sebebi ortalama trafik değil, ani eşzamanlılık. Normalde dakikada 5 istek gelen sunucu, bir paylaşımın ardından saniyede 30 istek görür. Statik sayfalar önbellekten dönerse sorun yok; ama sepet, ödeme ve kullanıcı paneli önbelleklenemez, her biri PHP ve veritabanı çalıştırır. Yani darboğaz doğrudan işlem hattına biner.
Çözüm üç katmanlı: statik içerik için CDN, dinamik sorgu sonuçları için nesne önbelleği, teslimat ve bildirim işleri için kuyruk. Kuyruk mantığı özellikle önemli; kod teslimi ve e-posta gönderimi istekle aynı anda yapılmak zorunda değildir. Bunları arka plana atan bir e-pin scripti kampanya anında ödeme sayfasını ayakta tutar, teslimatı birkaç saniye sonra tamamlar. Müşteri fark etmez, sunucu nefes alır.
Yedek, Log ve Güvenlik: Sunucu Planının Görünmeyen Yarısı
E-pin işinde veri kaybı sıradan bir aksaklık değildir; satılmış ama teslim edilmemiş kodlar, bakiyesi kaybolmuş bayiler ve kanıtlanamayan işlemler demektir. Bu yüzden yedekleme aynı sunucuda tutulmaz. Farklı bir lokasyona, şifreli ve geri yükleme testi yapılmış şekilde alınır. Test edilmemiş yedek, yedek değil temennidir.
Log tarafında üç kaydı asla kapatma: ödeme bildirimleri, stok hareketleri ve yönetici paneli girişleri. Güvenlikte ise yönetim yolunu gizlemek, iki adımlı doğrulama, dosya izinlerinin doğru ayarı ve web kökü dışına alınmış yapılandırma dosyası temel dörtlüdür. Bu dördü olmadan en pahalı sunucu bile güvenli sayılmaz.
| Kontrol Maddesi | Hedef Değer / Durum | Öncelik |
|---|---|---|
| PHP sürümü | 8.2 veya üzeri | Zorunlu |
| OPcache | Açık, en az 128 MB | Zorunlu |
| Veritabanı motoru | MySQL 8 / MariaDB 10.6+ InnoDB | Zorunlu |
| InnoDB buffer pool | RAM'in yaklaşık %40'ı | Yüksek |
| Disk tipi | NVMe | Yüksek |
| Cron sıklığı | Dakikalık çalışabilir | Zorunlu |
| SSL ve HTTPS zorlaması | Tam site yönlendirmeli | Zorunlu |
| Dış lokasyonda yedek | Günlük + geri yükleme testli | Zorunlu |
| Yapılandırma dosyası konumu | Web kökü dışında | Yüksek |
| Arka plan iş kuyruğu | Teslimat ve e-posta için aktif | Önerilir |
Sunucunu doğru kurgulanmış bir motora emanet et
Pinova, modern PHP sürümleriyle uyumlu, InnoDB kilit mantığına göre tasarlanmış sipariş akışı ve arka plan teslimat kuyruğuyla gelir. Aynı donanımda daha fazla sipariş kaldırır.
Paylaşımlı hostingle başlayıp sonra VPS'e geçebilir miyim?
Evet ve çoğu bayi için doğru yol budur. Geçişi kolaylaştırmak için baştan itibaren veritabanı yedeklerini düzenli al ve dosya yollarını mutlak değil göreli tut. Böylece taşıma birkaç saatlik iş olur.
Windows sunucu kullanabilir miyim?
Teknik olarak mümkün ama önerilmez. Cron, dosya izinleri ve önbellek araçları Linux tarafında hem daha stabil hem daha iyi belgelenmiştir. Sorun yaşadığında çözüm bulman da çok daha hızlı olur.
Kaç ürüne kadar aynı sunucuda kalabilirim?
Sınırı ürün sayısı değil, eşzamanlı sipariş yoğunluğu belirler. 50 bin ürünlü ama günde 40 sipariş alan bir site küçük kaynakta rahat çalışır; 500 ürünlü ama kampanya anında 300 sipariş alan site çok daha güçlü kaynak ister.
Redis veya benzeri bir önbellek şart mı?
Günlük 200 siparişin altında şart değil. Üzerine çıktığında oturum ve sorgu önbelleğini belleğe taşımak veritabanı yükünü belirgin biçimde azaltır ve panel ekranlarındaki gecikmeyi ortadan kaldırır.
Sonuç olarak sunucu planı, satın alma anında verilen tek bir karar değil; ciroyla birlikte revize edilen bir kaynak bütçesidir. Yazılımın bu bütçeyi verimli kullanıp kullanmadığını ise ancak çalışırken görürsün. canlı demo üzerinden panel ekranlarının yanıt hızını, sipariş akışını ve teslimat kuyruğunu kendi gözünle test et; ardından fiyat sayfasında hangi paketin kendi yük profiline oturduğuna karar ver.