Çoğu e-pin satıcısı kampanya gününü bir pazarlama meselesi sanır. Görseli hazırlarsın, indirim oranını belirlersin, sosyal medyada sayaç döner, mailler gider. Sonra saat 20:00 olur, kampanya açılır ve o güne kadar hiç sorun çıkarmamış siten üç dakika içinde açılmaz hâle gelir. İlk refleks hep aynıdır: “Sunucu yetmedi, paket yükseltelim.” Oysa o gece yaşanan şey nadiren ham güç eksikliğidir. Yaşanan şey, hiç ölçülmemiş bir sistemin ilk kez gerçek eşzamanlılıkla tanışmasıdır.
İşin sessiz tarafı şu: kapasite planlaması sunucu satın almakla başlamaz, kendi trafiğini tahmin etmekle başlar. Kaç kişinin aynı saniyede sepete tıklayacağını, kaç ödeme çağrısının aynı anda üçüncü parti servise gideceğini, kaç e-pin kodunun aynı stok satırından çekileceğini bilmiyorsan; aldığın sunucu ister 4 çekirdek olsun ister 32, sadece çöküşün saatini birkaç dakika öteler. Bu yazıda kampanya öncesi kapasite planlamasını, kullandığın e-pin scripti ile sunucu katmanını birlikte düşünerek kuracağız.
Kampanya Çöküşleri Neden Hep İlk On Dakikada Başlar?
Kampanya trafiği düz bir çizgi değildir, bir duvardır. Duyuru maili ve bildirim aynı dakikada gider, insanlar aynı anda siteye gelir. Normal bir günde saniyede 3-5 istek alan bir site, duyuru anında saniyede 40-70 isteğe çıkar. Bu ani sıçrama iki şeyi aynı anda tetikler: uygulama işçilerinin (PHP-FPM process, worker) tamamının meşgul olması ve veritabanı bağlantı havuzunun dolması. İşçiler meşgulse yeni istek kuyruğa girer, kuyruk uzadıkça bekleme süresi artar, kullanıcı sayfayı yeniler ve her yenileme kuyruğa yeni bir istek ekler. Böylece çöküş kendi kendini besler.
Bu kartopu etkisini anlamak kapasite planlamasının temelidir. Amacın “hiç yavaşlamamak” değil, yavaşlamanın kartopuna dönüşmemesini sağlamaktır. Bunun için üç şeye ihtiyacın var: yeterli işçi sayısı, hızlı biten sorgular ve kuyruk taştığında düzgün davranan bir uygulama katmanı. Üçü birden olmadan tek başına RAM eklemek sonucu değiştirmez.
Trafik Tahmini Yapmadan Paket Yükseltmek Neden Para Yakmak?
Kapasite hesabı için elinde üç sayı olmalı: kampanya duyurusunu göreceği tahmini kişi sayısı, bunların ilk 15 dakikada siteye gelme oranı ve kişi başına ortalama sayfa görüntüleme. 20.000 kişilik bir listeye mail attıysan, ilk çeyrek saatte tipik olarak %8-12’si gelir; bu 1.600-2.400 kişi demektir. Her biri ortalama 6 sayfa gezerse 15 dakikaya yaklaşık 12.000 istek yayılır, yani saniyede ortalama 13 istek. Ama trafik düzgün yayılmaz; tepe noktası ortalamanın 3-4 katıdır. Yani gerçek hedefin saniyede 40-50 istek.
Bu sayıyı bulduğunda sunucu tercihi bir tahmin değil, aritmetik olur. Ortalama yanıt süresi 200 ms olan bir sayfada tek işçi saniyede 5 istek karşılar; 50 istek için yaklaşık 10-12 aktif işçi, onların RAM tüketimi kadar bellek ve sorguları besleyecek veritabanı kaynağı gerekir. Burada kritik nokta şu: yanıt süresini 200 ms’den 600 ms’ye çıkaran kötü bir sorgu, ihtiyacın olan sunucu boyutunu üçe katlar. Kod optimizasyonu, donanımdan üç kat daha ucuz kapasitedir. İyi yazılmış bir dijital ürün satış scripti aynı donanımda üç kat fazla müşteriye hizmet eder.
| Tepe eşzamanlı istek (rps) | Önerilen vCPU / RAM | Uygulama işçisi | DB bağlantı havuzu | Önbellek stratejisi |
|---|---|---|---|---|
| 5-15 | 2 vCPU / 4 GB | 8-10 | 25 | Opcode + sayfa parçası |
| 15-40 | 4 vCPU / 8 GB | 16-20 | 50 | Opcode + Redis nesne önbelleği |
| 40-90 | 8 vCPU / 16 GB | 32-40 | 100 | Redis + tam sayfa önbellek (misafir) |
| 90-200 | 16 vCPU / 32 GB | 64-80 | 150-200 | Redis + CDN kenar önbelleği |
| 200+ | 2+ uygulama sunucusu | yük dengeleyici arkası | ayrı DB sunucusu | Okuma kopyası + kuyruk |
Asıl Darboğaz CPU Değil, Veritabanı Bağlantı Havuzu
Kampanya gecesi sunucu grafiklerine baktığında CPU %45’te görünürken sitenin açılmaması kafa karıştırır. Sebebi genelde bağlantı havuzudur. Her uygulama işçisi veritabanına bir bağlantı açar; işçi sayısını iki katına çıkardığında bağlantı ihtiyacı da ikiye katlanır. Veritabanı üst sınıra ulaştığında yeni bağlantılar reddedilir ve kullanıcı beyaz sayfa görür. CPU boştur çünkü kimse iş yapamıyordur.
İkinci gizli darboğaz yavaş sorgulardır. Ürün listeleme, kur dönüşümü, stok sayımı ve kampanya indirimi hesabı aynı sayfada çalışıyorsa tek sayfa yüklemesi 30-60 sorgu üretebilir. Normal trafikte bunu fark etmezsin; 50 rps’de saniyede 2.500 sorgu demektir. Kampanyadan önce yavaş sorgu kaydını açıp 100 ms üzerindeki her sorguyu indeksle ya da önbelleğe al. Kullandığın e-pin satış yazılımı sorgu sayısını sayfa başına düşüren bir mimariye sahipse bu iş büyük ölçüde senin için çözülmüş olur; nasıl çözüldüğünü özellikler bölümünde görebilirsin.
Kampanya gecesi kesintilerinin başladığı katman
- Veritabanı / bağlantı havuzu 45%
- Uygulama işçileri ve kuyruk 25%
- Ödeme ve kur API çağrıları 20%
- Ağ, CDN ve statik dosya 10%
E-pin Stok Kilidi: Kapasitenin Görünmeyen Tavanı
Fiziksel ürün satan bir sitede iki kişi aynı ürünü aynı anda alırsa en kötü senaryo stok eksiye düşer. E-pin tarafında ise aynı kodun iki müşteriye teslim edilmesi doğrudan para kaybı ve itibar kaybıdır. Bu yüzden düzgün yazılmış her e-pin satış scripti kod teslimini satır kilidi veya işlem (transaction) içinde yapar. Doğrusu budur ama bir yan etkisi vardır: kilit sırasında aynı stoktan almak isteyen diğer istekler bekler.
Kampanyada tek bir popüler ürüne yığılma olduğunda bu kilit kuyruğu kapasitenin gerçek tavanı hâline gelir. Sunucun 200 rps kaldırsa bile o tek stok satırı saniyede belki 30 teslim yapabilir. Çözüm kilidi kaldırmak değil, kilit süresini kısaltmaktır: teslim işlemi içinde mail göndermek, webhook atmak, log yazmak gibi yavaş işler yapma; onları kuyruğa devret. Kilit sadece “kodu seç, müşteriye ata, işaretle” kadar sürmeli. Bir de kampanyayı tek üründe toplamak yerine 5-6 ürüne yayarsan kuyruk doğal olarak paralelleşir.
Kampanya Öncesi 72 Saat: Hangi Ayarı Ne Zaman Değiştirmelisin?
Kapasite planlamasının en çok ihmal edilen kısmı zamanlamadır. Kampanya gününün sabahı sunucu yükseltmek, PHP sürümü değiştirmek veya önbellek eklemek en kötü fikirdir; çünkü yeni ayarın yan etkisini görecek zamanın kalmaz. Doğru düzen şu: kaynak yükseltmesi ve yapılandırma değişiklikleri en az 72 saat önce, yük testi 48 saat önce, sadece geri alınabilir küçük rötuşlar son 24 saatte.
Son 24 saatte yapılması gereken tek teknik iş izleme hazırlığıdır: yanıt süresi, hata oranı, veritabanı bağlantı sayısı ve kuyruk uzunluğu için eşikli uyarı kur. Kampanya başladıktan sonra grafik açıp bakmak yerine telefonun titremesini istiyorsun. Ayrıca bir geri dönüş planı hazırla: trafik beklentiyi aşarsa ağır sayfaları geçici olarak kapatabileceğin, ürün listelemeyi tam sayfa önbelleğe alabileceğin bir anahtar bulunsun. Bu anahtarı kampanya sırasında yazmaya çalışmak, batan gemide tekne çizmeye benzer.
Duyuruyu tek seferde 20.000 kişiye atmak yerine üç dilime böl ve aralara 10 dakika koy. Bu tek hamle tepe yükünü yaklaşık yarıya indirir ve aynı donanımla iki kat müşteriye hizmet etmeni sağlar.
Yazılım Tarafı Hazır Değilse Sunucu Yükseltmesi İşe Yaramaz
Kapasite planlamasında son ve en önemli gerçek şu: sunucu sadece bir kap, işi yapan kod. Sayfa başına 60 sorgu atan, önbellek kullanmayan, teslim işlemi içinde mail gönderen bir kurulum 16 çekirdekte de tıkanır. Buna karşılık sorgularını gruplayan, nesne önbelleği kullanan, ağır işleri kuyruğa alan bir epin yazılım altyapısı mütevazı bir sunucuyla kampanya gecesini sorunsuz geçirir.
Bu yüzden kapasite kararını verirken önce yazılımın davranışını ölç, sonra donanıma para harca. Elindeki kurulumun sayfa başına kaç sorgu attığını, önbelleğin gerçekten çalışıp çalışmadığını ve teslim akışının ne kadar sürdüğünü bilmiyorsan, planlama değil kumar oynuyorsun. Pinova’nın kaynak kullanımı ve önbellek mimarisi tam bu senaryolar düşünülerek kurulmuştur; hangi paketin hangi trafik seviyesine denk geldiğini fiyatlandırma bölümünde karşılaştırabilirsin.
| Kontrol maddesi | Ne zaman | Nasıl doğrularsın | Durum |
|---|---|---|---|
| Tepe rps tahmini hesaplandı | T-7 gün | Liste büyüklüğü x açılma oranı x 3,5 | Zorunlu |
| Yavaş sorgu kaydı açıldı ve temizlendi | T-5 gün | 100 ms üzeri sorgu listesi boş | Zorunlu |
| Sunucu/paket yükseltmesi tamamlandı | T-72 saat | Kaynak grafiği ve sürüm doğrulaması | Zorunlu |
| Nesne ve sayfa önbelleği doğrulandı | T-72 saat | Önbellek isabet oranı %80 üzeri | Zorunlu |
| Yük testi çalıştırıldı | T-48 saat | Hedef rps’de hata oranı %1 altı | Zorunlu |
| Stok kilidi süresi ölçüldü | T-48 saat | Teslim işlemi 150 ms altında | Önerilen |
| Uyarı eşikleri kuruldu | T-24 saat | Test uyarısı telefona düştü | Zorunlu |
| Acil sadeleştirme anahtarı hazır | T-24 saat | Tek tıkla ağır modül kapanıyor | Önerilen |
| Duyuru dilimlere bölündü | T-2 saat | Gönderim planı onaylandı | Önerilen |
| Veritabanı yedeği alındı | T-2 saat | Yedek geri yüklenebilir doğrulandı | Zorunlu |
Kampanya gecesini kaybetmek yerine altyapını sağlam kur
Pinova, e-pin ve dijital ürün satan işletmeler için kaynak dostu mimari, önbellek katmanı ve güvenli teslim akışıyla gelir. Kampanya trafiğinde ayakta kalan bir altyapıyı sıfırdan yazmak zorunda değilsin.
Kampanya için sunucumu kalıcı olarak mı yükseltmeliyim?
Hayır. Çoğu sağlayıcı saatlik ölçeklendirmeye izin verir. Kampanyadan 72 saat önce yükselt, kampanyadan 48 saat sonra düşür. Tek kural: yükseltmeyi test edecek kadar erken yap.
Kaç eşzamanlı kullanıcıya hazır olmam gerektiğini nasıl bilirim?
Duyuru göndereceğin kişi sayısını ilk çeyrek saatteki tipik %10 gelme oranıyla çarp, sayfa görüntüleme ortalamasına böl ve sonucu 3,5 ile çarp. Bulduğun sayı tepe istek hedefindir.
Önbellek kullanmak stok hatasına yol açar mı?
Doğru kurulursa açmaz. Ürün listeleme ve içerik sayfaları önbelleğe alınır; sepet, ödeme ve teslim adımları her zaman önbellek dışında bırakılır. Stok sayısı ise kısa ömürlü önbellekle gösterilir, teslim anında veritabanından yeniden doğrulanır.
Paylaşımlı hosting kampanya trafiği kaldırır mı?
Küçük ölçekte kaldırır ama işçi ve bağlantı sınırlarını sen belirlemediğin için tepe anını yönetemezsin. Tepe hedefin 15 rps’yi aşıyorsa kaynaklarını kendin ayarlayabileceğin bir sunucuya geçmek en düşük maliyetli sigortadır.
Kapasite planlaması korkutucu görünür ama özü basittir: tahmin et, ölç, darboğazı bul, erken düzelt. Bu döngüyü bir kez kurduğunda her kampanya öncesi yapacağın iş yarım güne iner ve o meşhur “site çöktü” mesajları geçmişte kalır. Altyapının bu döngüyü destekleyip desteklemediğini merak ediyorsan, Pinova’nın panel yapısını, teslim akışını ve kaynak davranışını kendi gözünle görmek için canlı demo üzerinden dolaşabilir, sonra kurulum adımına geçebilirsin.