Güncellemeyi Yükledin Ama Site Hâlâ Eski Kodu Servis Ediyor: OPcache'in E-pin Scriptinde Sessizce Sakladığı Gerçek

Bir akşam paneldeki hatayı düzelttin, dosyayı sunucuya yükledin, sayfayı yeniledin ve hata hâlâ orada. "Yükleme bozuk olmalı" deyip tekrar gönderdin. Yine aynı. Sonra tarayıcı önbelleğini temizledin, gizli sekmede denedin, başka cihazdan baktın. Değişen hiçbir şey yok. Nihayet bir de sunucuyu yeniden başlattın ve düzeltme bir anda çalıştı. O gece "sunucu tuhaflık yaptı" diye kapattın konuyu.

Çoğu kişi bunu rastgele bir arıza sanır; oysa tamamen öngörülebilir bir davranıştır. PHP, kodunu her istekte yeniden derlemez; derlenmiş hâlini bellekte tutar. Bu mekanizmaya OPcache denir ve bir e-pin satış scriptinin hızının büyük kısmını ona borçlusun. Ama aynı mekanizma, yanlış ayarlandığında güncellemeni günlerce görünmez kılar, daha kötüsü yarısı yeni yarısı eski bir kod tabanını canlıda çalıştırır. İşte tam olarak orada para kaybedilir.

OPcache aslında ne yapıyor, neden kapatmak çözüm değil?

PHP yorumlanan bir dildir. Her istekte dosyalar okunur, ayrıştırılır ve ara koda çevrilir. Yüz dosyalık bir dijital ürün satış yazılımında bu iş, istek başına ölçülebilir bir gecikme demektir. OPcache derlenmiş ara kodu paylaşılan bellekte tutar; ikinci istekte ayrıştırma adımı tamamen atlanır. Kazanç gerçektir ve kimse bundan vazgeçmek istemez.

Sorun yaşayan çoğu kişinin ilk refleksi OPcache'i tamamen kapatmaktır. Bu, ateşi düşürmek için termometreyi kırmaya benzer. Site anında yavaşlar, kampanya trafiğinde çöker ve sen de yine sunucu büyütmeye gidersin. Doğru çözüm kapatmak değil, geçerlilik kontrolünü ve dağıtım yöntemini düzeltmektir. Ayar birkaç satırdır; kaybettiğin zaman ise günlerle ölçülür.

Dosyayı değiştirdiğin halde neden eski kod dönüyor?

Cevap iki ayardadır. Birincisi zaman damgası kontrolünün açık olup olmadığı, ikincisi bu kontrolün kaç saniyede bir yapıldığı. Kontrol kapalıysa PHP dosyanın değiştiğini hiç fark etmez; bellekte ne varsa onu servis eder ve bu durum servis yeniden başlatılana kadar sürer. Kontrol açık ama sıklık yüksek bir değere ayarlanmışsa değişikliğin görünmesi için o kadar saniye beklemen gerekir.

Üçüncü ve en sinsi neden gerçek zaman çözünürlüğüdür. Dosya sistemleri değişiklik zamanını saniye hassasiyetinde tutar. Aynı saniye içinde iki kez üzerine yazdığın bir dosyada damga değişmeyebilir ve PHP dosyayı taze sanmaya devam eder. FTP ile hızlı ardışık düzeltme gönderen herkes bu tuzağa en az bir kez düşer. Bu yüzden dağıtımda dosyanın üzerine yazmak yerine geçici isimle yükleyip yer değiştirmek tercih edilir.

Dağıtım sırasında yarım kod çalışması neden tehlikeli?

Elli dosyayı tek tek FTP ile yüklerken, ilk dosya yeni ve son dosya hâlâ eskidir. Bu pencere birkaç saniye sürebilir; kampanya anında ise o birkaç saniyede onlarca sipariş geçer. Yeni ödeme sınıfını bekleyen eski bir sipariş dosyası, tanımsız metot hatası verir. Müşteri parayı gönderir, sipariş kaydı oluşmaz. Bu, teknik bir detay değil doğrudan mali kayıptır.

Profesyonel yaklaşım atomik dağıtımdır: yeni sürümü ayrı bir dizine tam olarak yükle, doğrula, sonra tek bir işlemle etkin dizini değiştir. Böylece hiçbir istek yarı yeni bir kod tabanı görmez. Bunu yapamıyorsan en azından bir bakım anahtarı kullan; dağıtım başlarken satış akışını kapat, bitince aç. Bir dakikalık bakım ekranı, çözülmeyen bir ödeme uyuşmazlığından çok daha ucuzdur.

Önbelleği temizlemenin güvenli yolu hangisi?

Önbelleği boşaltmak için sunucuyu yeniden başlatmak en kaba yöntemdir; aktif istekleri keser. Daha iyisi, PHP işleyici servisini nazikçe yeniden yüklemektir. En pratiği ise webroot dışında tutulmayan ama gizli bir anahtarla korunan küçük bir temizleme betiğidir: çağrıldığında yalnızca derlenmiş kod önbelleğini sıfırlar.

Burada iki kritik kural var. Birincisi bu betiğin kimlik doğrulaması olmalı; herkese açık bir temizleme adresi, saniyede yüz istekle çağrılıp sunucuyu dize getirmenin kolay yoludur. İkincisi temizleme işlemi dağıtımın sonunda çalışmalı, başında değil. Baştan temizlersen bellek yeni kod yerine eski kodla yeniden dolar ve hiçbir şey çözülmez. Bu sıralamayı yanlış kuran çok sayıda kurulum gördüm.

Paylaşımlı hostingde ne kadar kontrolün var?

Paylaşımlı bir pakette ayarların çoğuna doğrudan erişemezsin, ama eli boş da değilsin. Çoğu kontrol panelinde PHP seçenekleri bölümünden bellek boyutunu ve kontrol sıklığını düzenleyebilirsin. Bazı sağlayıcılar panelde tek tuşla önbellek temizleme sunar. Erişimin hiç yoksa, dosya yollarını sürümleyerek de sonuç alabilirsin: dosya adını değiştirdiğinde eski derlenmiş kayıt zaten geçersiz kalır.

Öte yandan, kendi kodunu sıfırdan yazıyorsan bu tuzakların hepsini tek tek keşfetmek zorundasın. Hazır bir e-pin yazılımı kullanmanın az konuşulan faydası budur: dağıtım sonrası temizleme kancası, sürüm damgası ve bakım kilidi zaten kutudan çıkar. Pinova'nın dağıtım akışını ve hangi kancaların hazır geldiğini özellikler bölümünde inceleyebilirsin.

Dağıtım, bir satış sisteminde en çok tekrarlanan ve en az test edilen işlemdir. Bir kez düzgün kurduğunda her güncelleme sıradan bir işe dönüşür; kurmadığında ise her düzeltme yeni bir bilinmezlik olur. Kendi akışını kurmadan önce doğru yapılmış bir örneği görmek istersen, yönetim paneli ve satış tarafının birlikte nasıl çalıştığını canlı demo üzerinden incele; ardından kendi kurulumun için fiyat seçeneklerine göz atabilirsin.