Üniversite siteleri yılın büyük kısmında sorunsuz çalışır, yoğun günlerde zorlanır. Bunun sebebi genellikle sunucunun küçük olması değildir. Sebep, o gün sayfaların çoğunun hazır kopyadan gelememesidir. Bu yazımızda Drupal'ın sayfaları nasıl sakladığını, CDN'in neyi hızlandırıp neyi hızlandırmadığını ve performans optimizasyonuna hangi sıradan başlanacağını sade bir dille anlatıyoruz.
Bir sayfa mart ayında yarım saniyede açılıyor, kayıt haftasının ilk sabahı on saniyede açılıyor. Site aynı site, kod aynı kod. Değişen tek şey, o gün sunucunun kaç sayfayı sıfırdan hazırlamak zorunda kaldığıdır. Drupal performans optimizasyonu da esas olarak bu sayıyı düşürmekle ilgilidir.
Üniversite sitesi ne zaman yavaşlar?
Yıl boyunca siteye gelenlerin çoğu giriş yapmamış kişilerdir. Aday öğrenci programlara bakar, veli iletişim sayfasını açar, arama motoru haberleri tarar. Bu ziyaretlerin tamamı hazır kopyadan karşılanabilir ve sunucu neredeyse hiç çalışmaz.
Yoğun günlerde ziyaretçi profili değişir. Siteye gelenlerin önemli kısmı artık giriş yapmış öğrencidir. Giriş yapan herkes için sayfa kişiselleşir ve kişiselleşen sayfa, herkes için saklanmış kopyadan gelemez. Sunucu aynı anda binlerce sayfayı sıfırdan hazırlamaya başlar.
Buna iki şey daha eklenir. Kontenjan ve ders programı gibi bilgiler başka sistemden okunur, eskimemeleri gerektiği için uzun süre saklanamazlar. Bir de akademik takvim ya da duyuru değiştiğinde, o bilgiyi gösteren bütün sayfaların yeniden hazırlanması gerekir.
Üçü aynı haftaya denk geldiğinde site yavaşlar. Optimizasyonun hedefi de yıl boyunca birkaç salise kazanmak değil, bu günleri sorunsuz geçirmektir.
Drupal sayfaları nasıl saklıyor
Drupal bir sayfayı hazırladıktan sonra onu saklar. Aynı sayfayı isteyen ikinci kişiye hazırlama işini tekrarlamadan, sakladığını gönderir. Sitenin hızlı görünmesinin asıl sebebi budur ve bu mekanizma kurulumla birlikte gelir.
Giriş yapmamış ziyaretçide
Burada her şey kolaydır. Herkes aynı sayfayı gördüğü için tek bir kopya yeterlidir. Program sayfaları, haberler ve iletişim sayfası binlerce kişiye aynı kopyadan gider. Sunucu bu ziyaretlerde neredeyse hiç çalışmaz.
Giriş yapmış kullanıcıda
Kişi giriş yaptığı anda sayfanın bir kısmı ona özel hale gelir. Adı, bildirimleri, dersleri. Artık herkes için saklanmış tek bir kopya kullanılamaz.
Drupal bu durumda sayfayı ikiye ayırır. Herkes için aynı olan bölümleri yine saklar, yalnızca kişiye özel bölümleri her seferinde yeniden hazırlar. Böylece sayfanın tamamı değil, küçük bir kısmı yeniden üretilir.
Kişisel bölümler yine de yavaşsa devreye BigPipe girer. Bu yöntemi ilk geliştiren Facebook oldu, Drupal da aynı yaklaşımı çekirdeğine aldı. Yaptığı iş basit. Sayfanın ortak bölümlerini hemen gönderir, kişisel bölümleri hazır oldukça arkadan yollar. Ziyaretçi boş ekrana bakmak yerine dolmaya başlamış bir sayfa görür. Drupal dokümantasyonuna göre bu özellik 8.5 sürümünden beri standart kurulumda varsayılan olarak açık geliyor, yani çoğu sitede zaten çalışıyor.
| Giriş yapmamış ziyaretçi | Giriş yapmış kullanıcı | |
|---|---|---|
| Sayfa nasıl gelir | Hazır kopyadan | Ortak bölümler hazır, kişisel bölümler yeniden hazırlanır |
| Sunucuya maliyeti | Neredeyse yok | Her ziyarette bir miktar iş |
| Yoğun günde riski | Düşük | Asıl yük burada |
Bir içerik değiştiğinde ne oluyor
Saklamanın zor tarafı doldurmak değil, zamanı gelince doğru sayfaları yenilemektir. Üniversite sitesinde aynı bilgi onlarca yerde görünür. Bir akademisyenin adı bölüm listesinde, ders sayfasında ve haber kartında birden durur.
Drupal her sakladığı sayfanın hangi içeriklere bağlı olduğunu kaydeder. O içerik değiştiğinde yalnızca ona bağlı sayfaları yeniler, diğerlerine dokunmaz. Bu sayede tek bir isim değişikliği bütün siteyi etkilemez.
Buradaki asıl hata, her değişiklikten sonra bütün önbelleği temizleme alışkanlığıdır. Bu, sitenin tamamını sıfırdan hazırlatır ve en kötü anda sunucuyu zorlar. Yapılması gereken, bu düğmeyi günlük bir alışkanlık olmaktan çıkarmaktır.
CDN neyi hızlandırır, neyi hızlandırmaz
CDN, sitenin dosyalarını dünyaya dağılmış sunuculardan sunan bir hizmettir. Görseller, videolar ve yazı tipleri ziyaretçiye en yakın noktadan gelir. Kampüs sitelerinde bu dosyalar sayfa ağırlığının büyük kısmını oluşturduğu için kazanç gerçektir.
Drupal tarafında bunu CDN modülü sağlıyor. Burada planlamayı etkileyen bir ayrıntı var. Modülün kararlı sürümü Drupal 9 ve 10 ile çalışıyor, Drupal 11 desteği ise henüz test aşamasında. Drupal 11 üzerinde çalışan bir kurumun bunu önceden bilmesi gerekiyor.
Burada sık yapılan bir hata var. CDN kurulduğunda performans sorununun çözüldüğü varsayılır. Oysa CDN hazır dosyaları dağıtır, sayfayı hazırlamaz. Giriş yapmış öğrencinin gördüğü kişisel sayfa her durumda kurumun kendi sunucusunda hazırlanır. Yoğun günlerdeki asıl yük de oradadır.
Üniversitelerin kendi bilgi işlem sayfaları bunu açıkça yazıyor. Büyük bir devlet üniversitesinin Drupal kılavuzu, site sahiplerine CDN'in yalnızca giriş yapmamış ziyaretçiler için çalıştığını, giriş yapmış kullanıcıların bu katmanı atladığını söylüyor. Stanford ise ayrımı bir adım öteye taşımış. Birim siteleri için merkezden yönetilen bir Drupal platformu sunuyor, yüksek trafikli siteler için ayrı bir barındırma seçeneği tanımlıyor. Yani bütün siteler aynı kefeye konmuyor.
Canlı veri gösteren sayfalar
Kontenjan, ders programı ve sonuç listesi gibi bilgiler başka sistemden gelir ve eskiyemez. Bu sayfalar saklanamadığı için sitedeki en pahalı sayfalardır.
Üç basit önlem işe yarıyor. Birincisi, canlı bölümü sayfanın geri kalanından ayırmaktır. Böylece yalnızca o küçük parça her seferinde yenilenir, sayfanın geri kalanı saklanmaya devam eder. İkincisi, saklama süresini sıfır yapmak yerine kısa tutmaktır. Kontenjan bilgisinin bir dakika gecikmeli olması çoğu durumda kabul edilebilir ve o bir dakika, diğer sisteme gidecek binlerce sorguyu engeller. Üçüncüsü, kaynak sistem yanıt vermediğinde sayfanın boş gelmemesini sağlamaktır. Son bilinen değeri saatiyle göstermek, boş ekrandan iyidir.
Bu sayfaların veri tarafını daha önce Drupal ile öğrenci bilgi sistemi entegrasyonu yazısında ele almıştık.
Çok siteli yapılarda durum
Birçok üniversite onlarca fakülte ve birim sitesini tek yapıdan yönetir. Burada yaygın bir yanılgı var. Siteler aynı yapıyı paylaştığı için saklama işinin de ortak olduğu düşünülür, oysa her sitenin kendi kopyaları vardır.
Bunun iki sonucu olur. Bir sitede yapılan iyileştirme diğerlerine kendiliğinden geçmez. Ayrıca aynı sunucuyu paylaşan siteler kaynakları da paylaştığı için, bir birimin yoğun günü diğer birimlerin sayfalarını yavaşlatabilir.
Bu yapının genel dengelerini Drupal multisite ile üniversite web sitelerinin yönetimi yazısında anlatmıştık. Performans açısından sonuç şudur: yoğunlaşan siteleri önceden belirleyip ayrı değerlendirmek gerekir.
Neyi ölçmek gerekir
Ölçüm araçlarının bir körlüğü var. Çoğu araç siteye giriş yapmadan ölçüm yapar. Yani yoğun günlerde zorlanan asıl sayfaları hiç görmez. Anasayfanız tam puan alırken ders seçim ekranı çökebilir.
Bu yüzden iki ayrı bakış gerekir. Birincisi, giriş yapmamış ziyaretçinin gördüğü sayfalardır. Google'ın hız ölçütleri bu tarafı değerlendirir ve arama sıralamasını da etkiler. Bu ölçütleri Drupal SEO yazısında ele almıştık. İkincisi, giriş yapmış kullanıcının gördüğü sayfaların sunucu tarafındaki ölçümüdür ve asıl sorun genellikle oradadır.
En işe yarar ölçüm ise zaten elinizin altında. Geçen yılın yoğun haftasındaki sunucu kayıtları, herhangi bir test aracından daha fazla bilgi verir. Hangi saatte hangi sayfaların istendiği ve hangi isteklerin yarıda kaldığı orada yazılıdır.
Optimizasyona nereden başlanmalı
Yoğun dönemden en az bir ay önce başlamak ve şu sırayı izlemek işe yarıyor.
Önce saklama özelliklerinin açık olduğu doğrulanır. Bu yarım saatlik bir kontroldür, ama kapalı kaldığı sitelerde tek başına en büyük farkı yaratır.
Sonra giriş yapmış kullanıcının gördüğü sayfalar gözden geçirilir ve içlerinde gerçekten kişiye özel olan bölümler belirlenir. Çoğu sitede bu bölümler sanıldığından azdır, geri kalanı saklanabilir hale getirilir.
Ardından canlı veri gösteren bölümler ayrılır, her birine makul bir süre verilir ve kaynak sistem yanıt vermediğinde ne gösterileceğine karar verilir.
Son olarak geçen yılın yoğun günü örnek alınarak bir deneme yapılır. Bu deneme giriş yapmış kullanıcı üzerinden yapılmalıdır, aksi halde asıl sorunlu sayfalar hiç denenmemiş olur.
Beklentiyi de baştan doğru kurmakta fayda var. Drupal bu iş için güçlü araçlar verir, ama bunlar kurulumla birlikte kuruma göre ayarlanmış gelmez. Hangi bilginin ne kadar eskiyebileceğine karar vermek teknik değil kurumsal bir karardır ve öğrenci işleriyle birlikte verilir.
Drupart bünyesindeki Drupal4edu ekibinin Yeditepe Üniversitesi, İstinye Üniversitesi ve Medipol Üniversitesi gibi kurumlar için geliştirdiği Drupal platformları, yoğun dönemleri bu yaklaşımla karşılayacak şekilde kurulur. Yaklaşımımızın ayrıntılarını eğitimde Drupal sayfasında bulabilirsiniz.
Drupal performans optimizasyonu hakkında sık sorulan sorular
Sunucuyu büyütmek yavaşlığı çözer mi?
Bir noktaya kadar çözer, ama en pahalı yoldur. Yoğun günlerde zorlanan sayfaların çoğu hazır kopyadan gelemediği için sıfırdan hazırlanır. Saklama ayarları düzeltildiğinde aynı sunucu çok daha fazla ziyaretçiyi karşılayabilir. Doğru sıra şudur. Önce ayarlar kontrol edilir, kişiye özel olmayan bölümler saklanabilir hale getirilir, sonra yine de yetmiyorsa donanım konuşulur.
CDN kurmak tek başına yeterli olur mu?
Olmaz. CDN görselleri, videoları ve yazı tiplerini dağıtır, bu da sayfa ağırlığını belirgin şekilde azaltır. Ancak giriş yapmış öğrencinin gördüğü kişisel sayfa her durumda kurumun kendi sunucusunda hazırlanır ve yoğun günlerdeki asıl yük odur. CDN'i faydalı bir tamamlayıcı olarak düşünmek, ondan ana çözüm beklemekten daha gerçekçi sonuç verir.
Kontenjan gibi anlık bilgiler saklanabilir mi?
Kısa süreyle saklanabilir ve çoğu durumda saklanmalıdır. Kontenjan bilgisinin bir dakika gecikmeli gösterilmesi genelde kabul edilebilir bir durumdur. Buna karşılık o bir dakika, diğer sisteme gidecek binlerce sorguyu engeller. Önemli olan bu süreyi bilerek belirlemek ve öğrenci işleriyle birlikte kararlaştırmaktır. Ayrıca kaynak sistem yanıt vermediğinde sayfanın boş gelmemesi, son bilinen değeri saatiyle göstermesi gerekir.
Her değişiklikten sonra önbelleği temizlemek gerekir mi?
Gerekmez ve kaçınılması gereken bir alışkanlıktır. Drupal, her sakladığı sayfanın hangi içeriklere bağlı olduğunu bildiği için değişen içeriğe bağlı sayfaları kendisi yeniler. Bütün önbelleği temizlemek ise sitenin tamamını sıfırdan hazırlatır ve bunu genellikle en yoğun anda yaparsınız. Bu düğmeyi istisnai durumlara saklamak, günlük bir refleks haline getirmemek gerekir.