Ödeme sayfası yavaş açılıyorsa hangi sunucu kayıtları incelenmeli?

Ödeme sayfasının yavaş açılması, yalnızca kullanıcı deneyimini değil, dönüşüm oranını ve gelir akışını da doğrudan etkiler. Bu nedenle sorunu “site yavaş” gibi genel bir başlık altında değerlendirmek yerine, hangi isteğin nerede beklediğini kanıtlayan kayıtlarla ilerlemek gerekir. Doğru sunucu logları incelendiğinde gecikmenin uygulama kodundan mı, veritabanından mı, üçüncü taraf ödeme servisinden mi yoksa hosting kaynaklarından mı geldiği daha net ayrıştırılır.

İlk bakılması gereken kayıt: Web sunucusu access log

Access log, ödeme sayfasına gelen isteklerin zamanını, durum kodunu, yanıt boyutunu ve çoğu yapılandırmada yanıt süresini gösterir. Özellikle ödeme adımı, sepet onayı, kupon kontrolü, kargo hesaplama ve ödeme sağlayıcıya yönlendirme URL’leri ayrı ayrı incelenmelidir.

Burada aranması gereken temel sinyaller şunlardır:

• 200 yanıtları uzun sürüyor mu? Sayfa çalışıyor görünse bile 3-5 saniyeyi aşan yanıtlar uygulama veya kaynak darboğazına işaret edebilir.
• 302 yönlendirmeleri zincir oluşturuyor mu? Gereksiz yönlendirmeler ödeme adımında hissedilir gecikme yaratır.
• 499, 502, 503, 504 kodları var mı? Kullanıcının isteği terk etmesi, gateway hataları veya zaman aşımı sorunları araştırılmalıdır.
• Belirli saatlerde yoğunlaşma var mı? Kampanya, reklam trafiği veya bot istekleri ödeme sayfasını etkileyebilir.

Error log ile görünmeyen uygulama hatalarını yakalama

Ödeme sayfası bazen tamamen hata vermeden yavaşlar. Error log bu noktada kritik bilgi sağlar. PHP warning, fatal error, memory limit uyarısı, dosya izin problemi veya eklenti çakışmaları burada görülebilir. WordPress tabanlı yapılarda ödeme eklentileri, kargo modülleri ve kampanya kuponları sık kontrol edilmelidir.

Yanlış yapılan yaygın bir değerlendirme, sadece kritik hatalara bakmaktır. Oysa tekrarlayan uyarılar da performansı düşürebilir. Örneğin her ödeme denemesinde dış API’ye başarısız bağlanma, görünürde sayfayı açsa bile arka planda saniyelerce bekleme oluşturabilir.

PHP-FPM ve uygulama çalışma kayıtları

PHP-FPM slow log, hangi PHP dosyasının veya fonksiyonun uzun süre çalıştığını gösterdiği için ödeme sayfası analizinde çok değerlidir. Sepet toplamı hesaplama, vergi kuralı, stok kontrolü veya ödeme sağlayıcı entegrasyonu yavaşsa bu kayıtlar üzerinden izlenebilir.

PHP tarafında kontrol edilmesi gerekenler

• max_children değerine ulaşılıp ulaşılmadığı
• request_slowlog_timeout eşiğinin aşılıp aşılmadığı
• Bellek limitine yaklaşan süreçler
• Uzun çalışan checkout, AJAX veya REST API istekleri

Bu veriler, yalnızca daha güçlü bir sunucuya geçme kararı vermeden önce incelenmelidir. Çünkü sorun kötü optimize edilmiş bir sorgu veya eklenti ise kaynak artırımı geçici rahatlama sağlar, temel problemi ortadan kaldırmaz.

Veritabanı slow query log kayıtları

Ödeme sayfasında ürün, sepet, kullanıcı, kupon, stok, kargo ve sipariş tablolarına aynı anda erişilebilir. MySQL veya MariaDB slow query log, hangi sorguların uzun sürdüğünü gösterir. Özellikle büyük sipariş geçmişi olan e-ticaret sitelerinde indeks eksikliği, şişmiş geçici tablolar veya ağır meta sorguları gecikmeye neden olabilir.

İnceleme sırasında sadece en uzun sorguya değil, çok sık tekrar eden orta uzunluktaki sorgulara da bakılmalıdır. 300 milisaniyelik bir sorgunun ödeme sayfasında 40 kez çalışması, tek başına birkaç saniyelik bekleme yaratabilir.

Ödeme sağlayıcı ve dış servis kayıtları

Ödeme sayfası yavaşlığı her zaman sunucu içinde oluşmaz. Sanal POS, taksit sorgulama, fraud kontrolü, kargo fiyatı hesaplama veya CRM entegrasyonu gibi dış servisler yanıtı geciktirebilir. Web sunucusu loglarında sayfa isteği uzun görünüyorsa, uygulama loglarında dış API çağrılarının süreleri ayrıca kontrol edilmelidir.

Burada dikkat edilmesi gereken nokta, hata yoksa problemin olmadığı varsayımına düşmemektir. 200 dönen bir API çağrısı 4 saniye sürüyorsa ödeme ekranı kullanıcıya yavaş açılır. Mümkünse her dış servis için yanıt süresi, zaman aşımı ve tekrar deneme kayıtları ayrı tutulmalıdır.

Sistem kaynak kayıtları: CPU, RAM, disk ve I/O

Sunucu erişim ve uygulama kayıtları tek başına yeterli olmayabilir. CPU yükü, RAM kullanımı, swap, disk I/O ve ağ gecikmesi metrikleriyle birlikte değerlendirme yapılmalıdır. Özellikle paylaşımlı hosting ortamlarında aynı fiziksel kaynağı kullanan farklı hesapların yoğunluğu da performansı etkileyebilir.

Hızlı kontrol listesi

• Ödeme saatlerinde CPU load olağan seviyenin üzerine çıkıyor mu?
• RAM yetersizliği nedeniyle swap kullanımı başlıyor mu?
• Disk yazma gecikmesi sipariş oluşturma anında artıyor mu?
• Cache devre dışı kalan ödeme adımlarında PHP süreçleri birikiyor mu?
• WAF veya güvenlik katmanı ödeme isteklerini yavaşlatıyor mu?

Logları birlikte yorumlarken nasıl ilerlenmeli?

En sağlıklı yöntem, tek bir yavaş ödeme denemesini zaman çizelgesiyle izlemektir. Kullanıcının ödeme sayfasına giriş zamanı access log’dan alınır; aynı zaman aralığında error log, PHP-FPM slow log, veritabanı slow query log ve dış servis kayıtları karşılaştırılır. Böylece varsayımla değil, kanıtla hareket edilir.

Kurumsal yapılarda bu analiz düzenli hale getirilmelidir. Kritik ödeme URL’leri için yanıt süresi eşiği belirlemek, log rotasyonunu doğru yapılandırmak ve kampanya dönemlerinden önce test trafiğiyle ölçüm yapmak operasyonel riski azaltır. Eğer sorun belirli trafik artışlarında tekrarlanıyorsa, mevcut hosting altyapısının CPU, bellek, veritabanı ve ağ kapasitesi ödeme akışına göre yeniden değerlendirilmelidir.

Pratik bir başlangıç için ödeme sayfasında yaşanan yavaşlık anına ait 10-15 dakikalık log aralığı ayrılmalı, önce HTTP durum kodları ve yanıt süreleri listelenmeli, ardından en uzun PHP süreçleri ve veritabanı sorguları eşleştirilmelidir. Bu yaklaşım, gereksiz eklenti değişiklikleri veya plansız sunucu taşıma kararları yerine ölçülebilir ve güvenilir bir iyileştirme planı oluşturmayı sağlar.