Kampanya Gecesi E-Pin Scriptin Neden Diz Çöküyor? Kapasite Planlamanın Kimsenin Anlatmadığı Matematiği

Çoğu işletme sahibi kapasite sorununu bir sunucu sorunu sanır: site yavaşladıysa RAM artırılır, CPU çoğaltılır, mesele kapanır. Sonra kampanya gecesi gelir, sunucu kaynakları yarı boşken site yine tıkanır. Çünkü çöken sunucu değildir; çöken, aynı anda işlenmeye çalışan iş sayısıdır. Kapasite planlama donanım satın almak değil, işlerin nerede beklediğini bilmektir.

E-pin ve dijital ürün satışında bu daha da keskindir, çünkü yükün şekli düzgün değildir. Normal bir günde saatte yüz sipariş alırsın, indirim duyurusundan sonraki ilk on dakikada üç yüz sipariş gelir. Ortalamaya göre kurulmuş bir e-pin satış scripti ortalama günü rahat taşır ama o on dakikada teslimat kuyruğu, ödeme geri dönüşleri ve stok düşümü aynı satırlarda birbirini bekler. Bu yazıda o on dakikayı hesaplamayı ve ona göre ölçeklemeyi anlatıyorum.

Sunucu çökmez, kuyruk çöker: darboğaz nerede?

Bir satış isteği geldiğinde sistem sırayla şunları yapar: ürünü okur, stoğu kilitler, ödemeyi doğrular, siparişi yazar, kodu havuzdan çeker, teslimatı loglar, bildirimi kuyruğa atar. Bu adımların çoğu hızlıdır; ikisi değildir. Stok kilidi ve teslimat kuyruğu sıralı çalışmak zorundadır, çünkü aynı kodun iki kişiye gitmesini engellemek başka türlü mümkün olmaz. Yük arttığında işte bu iki sıralı nokta tıkanır.

Pratik sonuç şudur: CPU kullanımı yüzde otuzda dururken site cevap vermez hâle gelir. Çünkü elli istek aynı satır kilidini bekler. Bu durumda sunucuyu büyütmek hiçbir şeyi düzeltmez; kilit kapsamını daraltmak, kuyruğu ayırmak ve teslimatı senkron akıştan çıkarmak düzeltir. İyi bir dijital ürün satış yazılımı ödeme onayını anında işler ama kod teslimini arka plandaki bir işçiye devreder; müşteri "hazırlanıyor" görür ve iki saniye sonra kodu alır. Böylece zirvede bekleyen istek sayısı doğrusal artmaz.

Zirve trafiğini nasıl hesaplarsın?

Hesap için üç sayıya ihtiyacın var: günlük sipariş sayısı, zirve çarpanı ve tek siparişin ürettiği iş adedi. Günde altı yüz sipariş alıyorsan ortalaman saatte yirmi beştir. Zirve çarpanını duyuru geçmişinden çıkarırsın; e-pin işinde dört makul bir başlangıçtır. Yani zirvede saatte yüz sipariş, dakikada bir buçuk sipariş beklersin. Bu sayı ürkütücü değildir ama tek siparişin altı ayrı işi tetiklediğini hatırla: dakikada dokuz iş, on dakikalık pencerede doksan iş.

Sonra bu işlerin en yavaşını ölç. Tedarikçiden kod çekme çağrısı iki saniye sürüyorsa, tek işçi dakikada otuz iş yapabilir; üç işçi doksan iş. Yani üç arka plan işçisi bu zirveyi taşır. Bu hesabı yaptığın an kapasite planlama tahminden çıkar, aritmetik olur. Ölçmediğin adımı ölçekleyemezsin kuralı burada devreye girer: her adımın süresini loglamıyorsan hangi işçiyi çoğaltacağını bilemezsin.

Veritabanı mı uygulama mı disk mi: hangisini büyütmelisin?

Tabloya göre yükün yarısı veritabanındadır, o yüzden ilk kazanç orada. Ama büyütmek yerine önce düzeltmek gerekir. Sipariş listesi ekranında tarih ve durum sütunlarında indeks yoksa her yönetici sayfası tüm tabloyu tarar; zirvede on yönetici sekmesi tek başına siteyi yavaşlatabilir. Aynı şekilde raporlar canlı tablodan çalışıyorsa satış anında rapor açmak kuyruk oluşturur.

Uygulama katmanında en büyük kazanç önbelleklemedir. Ürün listesi ve kategori sayfaları dakikalarca değişmez; bunları hazır HTML olarak sunmak zirvedeki sayfa oluşturma yükünün büyük kısmını siler. Diskte ise tek dikkat edilecek şey log yazımıdır: her isteği ayrıntılı loglayan bir epin yazılım kurulumu, yoğun anda kendi loguyla boğulur. Çözüm logu tamamen kapatmak değil, ayrıntı seviyesini yükseltip kritik olayları ayrı dosyaya yazmaktır.

Stok kapasitesi: e-pin havuzu tükenirse ne olur?

Kapasite planlamanın çoğu kez atlanan ayağı budur. Sunucun yetse de havuzunda kod yoksa satış duruyor. Daha kötüsü, havuz boşaldığında yazılım bunu bir hata olarak değil boş sonuç olarak döndürürse müşteri ödeme yapar, kod gelmez ve elinde iade yığını olur. Bu yüzden stok eşiği sunucu eşiği kadar önemlidir.

Kurgulaman gereken üç kural var. Birincisi, her ürün için eşik altı uyarısı: havuz tahmini bir günlük satışın altına düşerse bildirim gitsin. İkincisi, sıfır stokta ürünün otomatik olarak satıştan çekilmesi. Üçüncüsü, tedarikçi çağrısının başarısız olduğu durumda siparişin "beklemede" statüsünde açılıp ödemenin bloke edilmesi. Bu üçü kuruluysa stok tükenmesi bir kriz değil, planlı bir duraklama olur. Fiyat ve paket seçimini yaparken bu otomasyonların hangi seviyede geldiğine bakmak işine yarar; fiyat bölümünde hangi kapasite araçlarının standart olduğunu görebilirsin.

Ölçek basamaklarını önceden yazmak neden işini kolaylaştırır?

Kapasiteyi krizde büyütmek en pahalı yöntemdir, çünkü aceleyle alınan kararlar hep fazla ödemeye yol açar. Onun yerine basamakları önceden yaz: hangi ölçümde ne yapacaksın. Böylece karar anında düşünmek yerine uygulama yaparsın. Aşağıdaki tablo doğrudan kullanabileceğin bir basamak planıdır.

Kapasite planlama, kampanya gecesini heyecan yerine rutine çeviren şeydir. Basamakları yaz, ölçümleri kur, işçi sayısını aritmetikle belirle. Kuyruk, stok eşiği ve önbellek ayarlarının panelde nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinden bu ekranları açıp kendi zirve hesabını üzerine oturtabilirsin.