XML feed üreten sitelerde bellek kullanımı nasıl düşürülür?

XML feed üreten sitelerde bellek tüketimi çoğu zaman sayfa trafiğinden değil, feed hazırlanırken tüm verinin aynı anda belleğe alınmasından kaynaklanır. Ürün, stok, kategori, görsel ve fiyat bilgileri tek seferde işlendiğinde PHP süreci kısa sürede memory_limit sınırına yaklaşabilir. Bu durum özellikle WordPress, WooCommerce, pazar yeri entegrasyonları ve karşılaştırma siteleri için kritik hale gelir. Doğru yöntem, daha büyük bir hosting paketi seçmeden önce feed üretim mantığını daha kontrollü ve parçalı çalışacak şekilde düzenlemektir.

XML feed neden fazla bellek kullanır?

Bir XML feed oluşturulurken veritabanından kayıtlar çekilir, alanlar dönüştürülür, XML yapısı hazırlanır ve çıktı tarayıcıya ya da dosyaya yazılır. Sorun genellikle bu adımların tamamının tek büyük dizi üzerinde yürütülmesidir. Örneğin 20.000 ürünün tüm meta verileriyle birlikte bir PHP array içine alınması, gerçek ürün sayısından çok daha yüksek bellek tüketimine yol açar.

Ek olarak görsel URL’leri, varyasyonlar, kampanya fiyatları ve özel alanlar her ürün için tekrar tekrar sorgulanıyorsa sunucu hem bellek hem CPU tarafında zorlanır. Bu nedenle yalnızca memory_limit değerini artırmak geçici rahatlama sağlar; kalıcı iyileştirme için veri akışının nasıl yönetildiğine bakmak gerekir.

Belleği düşürmenin en etkili yolu: akış tabanlı üretim

Feed oluştururken tüm XML’i bir değişkende biriktirmek yerine satır satır dosyaya yazmak bellek kullanımını ciddi ölçüde azaltır. Bu yaklaşımda uygulama her ürünü işler, XML parçasını oluşturur, dosyaya yazar ve bir sonraki ürüne geçer. Böylece bellekte yalnızca o an işlenen küçük veri kümesi tutulur.

WordPress tarafında bu mantık, büyük diziler oluşturmak yerine sayfalama ile ürün çekmek ve her sayfayı işledikten sonra değişkenleri serbest bırakmak şeklinde uygulanabilir. Özellikle büyük kataloglarda 250, 500 veya 1000 kayıtlık parçalarla çalışmak daha güvenlidir. En uygun parça boyutu ürün alanlarının genişliğine ve sunucu kaynaklarına göre test edilmelidir.

Veritabanı sorgularını daraltın

Feed için gerekli olmayan hiçbir alan çekilmemelidir. Sadece ürün adı, fiyat, stok, kategori ve zorunlu nitelikler kullanılacaksa tüm ürün nesnesini yüklemek yerine seçili alanları almak daha verimli olur. WordPress’te gereksiz meta sorguları, sınırsız post sorguları ve tekrarlayan kategori okumaları bellek tüketimini artırır.

Pratik kontrol listesi

• Tek seferde tüm ürünleri çeken sorguları sayfalı hale getirin.
• Gereksiz ürün meta alanlarını feed kapsamından çıkarın.
• Kategori, marka ve para birimi gibi tekrarlı verileri kısa süreli önbelleğe alın.
• Varyasyonlu ürünlerde yalnızca gönderilmesi gereken varyasyonları işleyin.
• Feed üretimi tamamlandığında büyük değişkenleri temizleyin.

Canlı üretim yerine dosya tabanlı feed kullanın

Her feed isteğinde XML’i baştan üretmek, yüksek trafikli sitelerde gereksiz kaynak tüketimine neden olur. Daha sağlıklı yöntem, feed’i belirli aralıklarla arka planda oluşturup statik XML dosyası olarak sunmaktır. Böylece kullanıcı, bot veya entegrasyon servisi feed URL’sine eriştiğinde PHP tekrar ağır işlem yapmaz.

Bu yapı için WordPress cron kullanılabilir; ancak yoğun kataloglarda sistem cron daha kararlı sonuç verir. Feed’in hangi sıklıkta yenileneceği iş modeline göre belirlenmelidir. Stok ve fiyatlar sık değişiyorsa saatlik, daha durağan kataloglarda günde birkaç kez üretim yeterli olabilir.

PHP bellek limitini artırmak her zaman çözüm değildir

Memory_limit değerini yükseltmek bazı durumlarda gereklidir; ancak hatalı feed mimarisini gizleyebilir. Limit artırıldığında işlem tamamlanıyor gibi görünse de eş zamanlı feed istekleri geldiğinde sunucu genel performansı düşebilir. Bu nedenle önce sorgu, sayfalama, önbellek ve dosyaya yazma yaklaşımı iyileştirilmelidir.

Yine de büyük ölçekli e-ticaret sitelerinde kaynak sınırları önemlidir. Paylaşımlı paketlerde uzun süren PHP süreçleri kesilebilir veya I/O sınırlarına takılabilir. Bu noktada mevcut hosting paketi; CPU, RAM, inode, disk I/O ve işlem süresi limitleri açısından değerlendirilmelidir. Sorun yalnızca feed sırasında yaşanıyorsa önce yazılım optimizasyonu, tüm sitede yaşanıyorsa altyapı analizi yapılmalıdır.

XML boyutunu ve alan yapısını sadeleştirin

Feed’e eklenen her alan hem çıktı boyutunu hem işleme maliyetini artırır. Pazar yeri veya reklam platformu zorunlu tutmuyorsa uzun açıklamalar, gereksiz özel etiketler, tekrar eden görsel alanları ve boş nitelikler çıkarılmalıdır. XML içinde boş tag üretmek de gereksiz şişkinlik yaratır.

Görsellerin kendisi XML içinde taşınmamalı, yalnızca URL olarak verilmelidir. Açıklama alanlarında HTML temizliği yapılıyorsa bu işlem her üretimde maliyet oluşturabilir. Mümkünse temizlenmiş açıklama önceden hazırlanmalı veya önbellekten okunmalıdır.

Hata ayıklama ve izleme nasıl yapılmalı?

Bellek kullanımını düşürmek için önce en çok tüketim yapan adımı görmek gerekir. PHP error log, WordPress debug log ve sunucu izleme araçları birlikte değerlendirilmelidir. Feed üretimi sırasında hangi sorgunun yavaşladığı, hangi ürün grubunda hata oluştuğu ve işlem süresinin nerede arttığı takip edilmelidir.

Sık yapılan hatalar

• Memory limit hatasını yalnızca limit artırarak çözmeye çalışmak.
• Feed URL’sini herkesin canlı olarak tetiklemesine izin vermek.
• Ürünleri tek büyük diziye alıp sonra XML’e dönüştürmek.
• Önbelleğe alınabilecek kategori ve marka verilerini her üründe yeniden sorgulamak.
• Feed üretim zamanını yoğun trafik saatlerine denk getirmek.

Sağlıklı bir yapı için feed üretimi düşük trafik saatlerinde planlanmalı, çıktı dosyası kontrol edilmeli ve başarısız üretimde eski çalışan dosya hemen silinmemelidir. Böylece entegrasyon servisleri boş veya hatalı XML ile karşılaşmaz. Bellek kullanımı düzenli ölçüldüğünde, hangi optimizasyonun gerçekten fayda sağladığı net biçimde görülebilir.