Drupal Web Sitesinde Teknik Performans İzleme

Drupal; esnek içerik tipleri, alanlar, taksonomi ve güçlü izin sistemiyle kurumsal düzeyde tercih edilen bir CMS’dir. Ancak Drupal’la gerçekten hızlı bir deneyim sunmak, yalnızca birkaç önbellek eklentisi kurmakla elde edilmez. Performans; ölçmek, gözlemlemek, alarm üretmek, kök neden (root cause) analizi yapmak ve tekrar edilebilir iyileştirme döngüleri oluşturmakla kalıcı hâle gelir. Başka bir deyişle, hız bir özellik değil; süreçtir.
1) İzleme Stratejisinin Temelleri: Neyi, Neden, Nasıl Ölçüyoruz?
Hedef: Kullanıcı deneyimine doğrudan etki eden ölçütleri sistematik olarak takip etmek.
-
İş hedefleri → teknik metrikler: Dönüşüm, etkileşim, SEO görünürlüğü gibi hedefleri LCP/INP/CLS, TTFB, hatalı istek oranı, uptime ve cache isabeti ile ilişkilendirin.
-
Katman yaklaşımı: Kullanıcı (RUM) → Uygulama (Drupal) → Sunucu (PHP-FPM, Nginx/Apache) → Veritabanı (MySQL/PostgreSQL) → Depolama → Ağ → CDN/Edge.
-
Gözlemlenebilirlik üçlüsü: Log (ne oldu?), Metrik (ne kadar oldu?), İz (Trace) (nasıl oldu?).
-
SLO/SLA: Hizmet düzeyi hedefleri (SLO) koyun; açıkça ihlal eşiği ve hata bütçesi tanımlayın.
Uygulama: “Her coğrafyada LCP < 2.5s, INP < 200ms, uptime ≥ %99.9” SLO’ları belirlenir; ihlal durumunda otomatik alarm + olay bileti açılır.
2) “Golden Signals” ve Drupal’a Uygulaması
Dört altın sinyal: gecikme (latency), trafik (traffic), hata (errors), doygunluk (saturation).
-
Gecikme: PHP-FPM istek süresi, Nginx upstream latency, DB sorgu süreleri, uygulama iç render süresi.
-
Trafik: RPS (Requests Per Second), eşzamanlı kullanıcılar, CDN’den edge hit sayıları.
-
Hatalar: 5xx/4xx oranı, PHP error logları, Drupal
watchdog
olayları. -
Doygunluk: CPU, bellek, disk IO, bağlantı havuzu, DB kilitleri.
Kontrol listesi: Her sinyal için target/alert eşikleri ve panolar (Grafana/Kibana) oluşturun.
3) Core Web Vitals (CWV) ve Gerçek Kullanıcı Ölçümü (RUM)
Neden? Google sıralaması, kullanıcı memnuniyeti ve dönüşüm üzerinde doğrudan etkili.
-
LCP: Hero görsel/başlık render süresi;
preload
, kritik CSS, resim optimizasyonu ile iyileştirilir. -
INP: Kullanıcı etkileşim gecikmesi; büyük JS paketlerinin bölünmesi, event işleyicilerinin optimize edilmesi.
-
CLS: Düzen kayması; boyut öznitelikleri, aspect-ratio, yer tutucu kullanımı.
-
RUM: Gerçek tarayıcılardan toplanan metrikler (örn. Boomerang, web-vitals, 3P RUM); segmentler: cihaz, ülke, ağ tipi.
Vaka: Mobilde LCP’nin 3.4s olduğu görüldü. Hero görsel preload
, srcset/sizes
yeniden düzenleme ve kritik CSS ile 2.1s’e düştü; dönüşüm %7 arttı.
4) Sentetik Testler: Lighthouse, WebPageTest ve CI Entegrasyonu
Amaç: Değişikliklerin performansı bozup bozmadığını önceden görmek.
-
Senaryolar: Ana sayfa, kategori listesi, tek içerik, arama ve form gönderimi.
-
Tekrarlanabilir ölçüm: Soğuk ve sıcak cache koşulları; farklı coğrafyadan test.
-
CI’da kapı (gate): LCP/INP/CLS eşiği aşılırsa dağıtım bloklansın; rapor PR’a eklenir.
Uygulama: Her PR’da Lighthouse skoru karşılaştırması; -5 puan düşüşte otomatik uyarı.
5) Sunucu Tarafı Metrikleri: Nginx/Apache ve PHP-FPM
Nginx/Apache: İstek sayısı, 2xx/3xx/4xx/5xx dağılımı, upstream gecikmesi, açık bağlantı sayısı.
PHP-FPM: Havuz başına süreç sayısı, kuyruk uzunluğu, yavaş istek günlükleri, max_children
doyumu.
Aksiyon: pm
ayarı (static/dynamic/ondemand), max_requests
döngüsü, request_terminate_timeout
ile asılı (hung) süreçleri engelleyin.
Vaka: Yoğun saatlerde php-fpm
kuyruğu uzuyordu; pm.dynamic
→ pm.ondemand
, max_children
ayarı ve opcache optimizasyonu ile gecikme %25 azaldı.
6) Veritabanı İzleme: MySQL/PostgreSQL ve Drupal Özgü Paternlere Dikkat
-
Temel metrikler: Sorgu/saniye, yavaş sorgu sayısı, kilitlenme (lock), buffer pool hit ratio, replikasyon gecikmesi.
-
Drupal paterni:
node
,node_field_data
,cache_*
,watchdog
,queue
,sessions
tabloları;field_*
parçalanması. -
İyileştirme: İndeksler, sorgu planı analizi, tekrarlı meta sorgularına cache, gereksiz revizyon temizliği.
Uygulama: Kategori listesinde LIKE
içeren ağır sorgu tespit edildi; uygun indeks + sayfa cache ile TTFB %30 iyileşti.
7) Drupal İç Gözleri: Render Pipeline, Cache Bin’ler ve Hook Zamanlaması
-
Cache katmanları: Page cache, Dynamic Page Cache, Render Cache, Entity/Route cache, Twig cache.
-
Cache bin izleme:
cache_render
,cache_page
,cache_data
hit/miss oranları. -
Hook zamanlama:
hook_init
,hook_entity_view
,hook_form_alter
gibi kancaların maliyeti; XHProf/Xdebug profilinde fonksiyon sıcak noktaları.
Kontrol listesi: Cache anahtarları (cache keys), bağlamlar (contexts) ve etiketler (tags) doğru mu? Yanlış etiketleme, gereksiz invalidasyona yol açar.
8) Profilleme Araçları: Webprofiler, XHProf/Xdebug ve Blackfire
-
Webprofiler: İstek başına zaman çizelgesi, sorgu sayıları, Twig render süreleri.
-
XHProf/Xdebug: Fonksiyon bazlı CPU/zaman grafikleri; sıcak noktaları saptama.
-
Blackfire/New Relic APM: Üretimde düşük yükle detaylı iz; dağıtım öncesi/sırası karşılaştırmalar.
Vaka: Menü ağacı oluşturucu fonksiyonun O(N²) çalıştığı görüldü; sonuçları cache’leyip karmaşıklığı düşürerek INP iyileştirildi.
9) Loglama Disiplini: Watchdog, Syslog ve Yapılandırılmış Loglar
-
Drupal watchdog: Kanallar (php, cron, user, security); kritik hatalarda alarm.
-
Syslog/JSON: RFC5424 biçimi, korelasyon ID (trace_id) ile çoklu hizmet eşleştirmesi.
-
Log rotasyonu: Disk dolması → performans sorunlarına sebep olabilir; günlük boyutu ve saklama politikası belirleyin.
Uygulama: 500 hatalarında otomatik olay bileti ve sorumlu kişiye bildirim; RCA (root cause analysis) şablonu zorunlu.
10) Metrik Toplama ve Panolar: Prometheus, Grafana, ELK/OpenSearch
-
Exporter’lar: Nginx/Apache, PHP-FPM, MySQL, node exporter; Drupal özel metrikleri için custom endpoint.
-
Panolar: Golden signals, CWV, cache hit ratio, DB gecikme, cron/queue durumu, CDN edge hit.
-
Uyarılar: Threshold ve anomali tabanlı alarmlar; iş saati dışı on-call.
Vaka: Anomali tespiti, belirli saatlerde dalgalanan DB gecikmesini yakaladı; yedekleme penceresi ile çakışma giderildi.
11) İz (Tracing) ve OpenTelemetry: Uçtan Uca Akış Görünürlüğü
-
Dağıtık izleme: Reverse proxy → PHP uygulama → DB/Redis → harici API zincirini tek izde görmek.
-
OpenTelemetry SDK: PHP ajanı ile span’ler; yavaş adımlar görselleştirilir.
-
Kullanım: Checkout akışında “en yavaş 5 span” raporu; hata oranı ile korelasyon.
Uygulama: Ödeme doğrulaması API’si ~1.8s gecikme yaratıyordu; timeout + retry + circuit breaker ile kullanıcı akışı hızlandı.
12) Önbellekleme ve Invalidation: Dinamik Sayfada Hız Nasıl Korunur?
-
Page vs Dynamic Page Cache: Giriş yapmamış kullanıcılar → page cache; oturumlu kullanıcılar → dynamic page cache.
-
Render cache: Bileşen bazında; varyasyon (contexts) doğru seçilmezse cache kaçırılır.
-
CDN: Edge TTL’leri, varyantlar, cache key normalization.
-
Invalidation: İçerik güncellemede yalnız ilgili etiketlerin (tags) temizlenmesi.
Vaka: Haber portalında tek bir içerik güncellemesi tüm sayfaları purge ediyordu; cache tags doğru ayarlanınca edge hit oranı %75→%92.
13) Queue ve Cron Performansı: Arka Plan İşleri Gözden Kaçmasın
-
Cron: Sistem cron tercih edin; Drupal cron’u trafikle tetiklemeyin.
-
Queue: Büyük içe aktarımlar, medya işleme, bildirimler; batch boyutu, deneme (retry), zaman aşımı (timeout) izlenmelidir.
-
Görünürlük: “Bekleyen iş” grafiği ve ortalama tamamlama süreleri; iş birikimi alarmı.
Uygulama: Cron sırasında yedekleme çalışıyor, DB kilitleniyordu; bakım penceresi ve cron zamanlaması ayrılarak hızlandı.
14) Arama Katmanı: Solr/Elasticsearch Sağlığı ve Gecikmeleri
-
Metrikler: Sorgu gecikmesi, indeksleme kuyruğu, heap/bellek kullanımı, GC duraklamaları.
-
İndeks stratejisi: Incremental reindex; büyük reindekslerde okuma kopyası ile çift geçiş.
-
Fallback: Arama down ise basit Drupal aramasıyla degrade gracefully.
Vaka: Kampanya sırasında arama 429 döndürüyordu; rate limit ve önbelleklenmiş popüler sorgular ile stabil hale getirildi.
15) Medya ve Statik Varlık Teslimi: Boyut, Format ve Dağıtım
-
WebP/AVIF dönüşümü,
srcset/sizes
,loading="lazy"
,decoding="async"
. -
CDN optimizasyonu: Bölgesel replikasyon, görsel işleme edge’de, cache-key’de parametre normalizasyonu.
-
CLS önleme:
width/height
öznitelikleri ve CSS oran kasası.
Uygulama: Görsel ağırlıklı sayfalarda ortalama boyut %40 azaldı; LCP 900 ms iyileşti.
16) CDN/Edge Metrikleri: Origin’i Boğmadan Hız
-
Edge hit ratio, origin fetch oranı, TTFB (edge), coğrafi dağılım.
-
Kurallar: Dinamik vs statik ayrımı; kişiselleştirilmiş içerikte
cache-bypass
stratejisi; stale-while-revalidate. -
Alarm: Edge hit düşüşü → origin aşırı yükü; otomatik sağlık denetimi.
Vaka: Yanlış varyant anahtarı yüzünden hit oranı %50’ye düştü; varyant onarımından sonra %90’a çıktı.
17) Yük Testi ve Kapasite Planlama: “Ne Kadar Trafiği Kaldırıyoruz?”
-
Araçlar: k6, JMeter, Locust; gerçekçi senaryolar (okuma/yazma karışımı).
-
Profiller: Soğuk/sıcak cache, CDN ile/olmadan, mobil/masaüstü dağılımı.
-
Hedef: Başarılı istek oranı ≥ %99, P95 yanıt süresi sınırları, hata oranı ≤ %1.
Uygulama: Lansman öncesi testte max_children
yetersizliği keşfedildi; ayar ve autoscale ile pik trafik başarıyla karşılandı.
18) Olay (Incident) Yönetimi ve SLO İhlalleri
-
Tetik: SLO ihlali → olay bileti → rol ve sorumlular.
-
Runbook: İlk 5 dakika: (1) Alarm doğrulama, (2) Cache/CDN bypass kontrol, (3) Son dağıtım diff, (4) Geri dönüş (rollback).
-
RCA: Kök neden, etkilenim kapsamı, düzeltici/önleyici faaliyet (CAPA).
Vaka: Dağıtım sonrası CLS arttı; şablon değişikliğinde width/height
kalkmıştı. Rollback + hotfix ile P95 CLS < 0.1’e döndü.
19) İyileştirme Oyun Kitabı (Playbook): Hız Sorunlarına Hızlı Çözümler
-
Yavaş sayfa: Query profili → Cache stratejisi → Blok render analizi → Görsel optimizasyon.
-
Yüksek TTFB: PHP-FPM kuyruğu, DB kilitleri, harici API yavaşlığı; timeout ve circuit breaker.
-
Yüksek INP: Büyük JS paketleri; kod bölme (code-splitting), idle-until-urgent etkileşim.
-
Yüksek CLS: Boyut öznitelikleri, font ön-yükleme, reklam/third-party yer tutucuları.
Kontrol listesi: Her soruna karşı 3 hızlı ve 3 kalıcı çözüm maddesi içeren şablon.
20) Vaka Çalışması 1: İçerik Ağır Kurumsal Portal
Sorun: Akşam 20:00-23:00 arası P95 LCP kötüleşiyor.
Analiz: Cron yedeklemeyle çakışıyor; CDN edge purge’leri gereğinden geniş.
Çözüm: Yedekleme penceresi değişti; cache tags ile hedefli invalidation; edge hit %88→%94.
21) Vaka Çalışması 2: Video Odaklı Yayın
Sorun: INP yüksek, mobilde etkileşim gecikiyor.
Analiz: Üçüncü taraf oynatıcı senkron blokluyor; DOMContentLoaded
sonrası ağır init.
Çözüm: IntersectionObserver ile lazy init, JS bölme; INP P75 310ms → 160ms.
22) KPI Panosu Tasarımı: “Bir Bakışta Sağlık”
Bölümler:
-
Kullanıcı deneyimi: LCP/INP/CLS (RUM + sentetik), hata oranı.
-
Uygulama: Cache hit ratio, PHP-FPM kuyruğu, DB sorgu gecikmesi.
-
Edge/CDN: Edge hit, origin fetch, coğrafi performans.
-
İş metrikleri: Dönüşüm, oturum süresi, sayfa/oturum.
İlke: Kırmızı/amber/yeşil eşikler; üstte özet, altta ayrıntı.
23) Maliyet ve ROI: Performansın Ekonomisi
-
Doğrudan getiriler: Dönüşüm artışı, SEO görünürlüğü, destek biletlerinde azalma.
-
Dolaylı getiriler: Altyapı ölçek maliyetinde düşüş (yük başına CPU/dk), geliştirici verimliliği.
-
Ölçüm: İyileştirme öncesi/sonrası karşılaştırma; “1 sn LCP iyileşmesi = X% dönüşüm artışı” modeli.
Vaka: Görsel optimizasyon + CDN edge işleme ile bant genişliği faturası %22 düştü.
24) Güvenlik ve Performans: WAF, Bot Yönetimi, Oran Sınırları
-
WAF: Kötü isteklerin PHP’ye ulaşmasını engelleyerek CPU’yu rahatlatır.
-
Bot yönetimi: Scraper/credential stuffing atakları; rate limit + tarayıcı doğrulama.
-
Gözlem: WAF logları ile uygulama metriklerini korele edin; yanlış pozitifleri azaltın.
Uygulama: Bot trafiği temizlenince 5xx oranı ve ortalama yanıt süresi belirgin düştü.
25) Erişilebilirlik ve Performans: Çatışma Değil, Sinerji
-
Erişilebilirlik iyileştirmeleri (odak görünürlüğü, semantik HTML) genellikle performansa da katkı sağlar.
-
Örnek: Karmaşık ARIA widget’ı yerine basit HTML + progressive enhancement; JS maliyeti azalır, INP iyileşir.
26) Yönetişim: Dokümantasyon, Eğitim ve Operasyonel Disiplin
-
Runbook’lar: Olay yönetimi, rollback, cache temizliği, cron durdurma/başlatma adımları.
-
Eğitim: Yeni ekip üyelerine “Drupal performans 101”; araçlar ve panolar.
-
İç denetim: Üç ayda bir performans denetimi; backlog’a iyileştirme maddeleri.
Sonuç: Performans Bir Proje Değil, Sürekli Bir Pratik
Drupal sitelerinde teknik performans izleme; tek seferlik hızlandırma çalışmalarıyla bitmez. RUM + sentetik test kombinasyonu, sunucu/DB/uygulama metrikleri, dağıtık izleme, cache ve CDN stratejileri, cron/queue gözetimi ve olay yönetimi ile desteklenen bir operasyonel kültür gerektirir. Bu kültür sayesinde hızınız, yalnızca bugün değil; yeni özellikler, sürüm güncellemeleri, trafik sıçramaları ve beklenmedik durumlar karşısında da ölçülebilir, kanıtlanabilir ve sürdürülebilir kalır.
Kısacası; hız bir sayı değil, organizasyonel yetkinliktir. Doğru metrikleri seçip tutarlı biçimde izlediğiniz, alarm ve runbook’larla otomasyona bağladığınız ve düzenli post-mortem + RCA disipliniyle öğrendiğiniz sürece; Drupal projeniz yalnızca daha hızlı değil, aynı zamanda daha dayanıklı ve daha ekonomik olur. Bugün panoları ve eşikleri kurun, yarın kriz anında değil; grafikte konuşun.