Şecere Mantığı Hatası
E-devletin verdiği şecereye baktığımız zaman;
- Annesinin Annesinin Babasının Babası ...
- Annesinin Annesinin Babasının Annesi ...
- Babasının Annesinin Babasının Annesi ...
- Annesinin Annesinin Annesinin Babası ...
Anneler, anneanneler aileye dışarıdan katılırlar. Annemin annesinin babasının annesi benim akrabam bile sayılmaz. Şecere baba üzerinden takip etmeli. Annenin, anneannenin anneannesi üzerinden şecere takibi olmaz. Her baba zikredilirken onun babası ve annesi zikredilmeli. Ama onun annesinin soyunun şeceresi üzerinde devam edilmemeli.
Burada maksimum 5 kuşağa kadar gidiyor. Halbuki baba üzerinden gidilseydi bu sayı iki katına kadar çıkabilirdi.
Benim şeceremde zikredilen en eski dedem 1887 doğumlu Sarıkamış gazisi büyük dedem Ahmet Çetin. 1974 yılında vefat etmişti. Halbuki biz aile olarak en az bunun üç atasını biliyoruz.
Vatana millete hayırlı olsun.
😄
Teknik Aksaklıklar
Herkes eski kayıtlar üzerinden kendi üst ve alt soy ağacı şeceresini sorgulayıp görüntüleyebilecekti.
Ancak ilk dakikadan itibaren sorunlar patlak verdi. Aşırı talep bir anda sistemin çökmesine sebep oldu. Çünkü bu sorgunun üretilebilmesi için öngörülen süre 3 dakika olarak görünüyordu. Bu da bir anda kuyrukta bekleyen yüzbinlerce talebin yığılmasına ve sistemin kilitlenmesine sebep oldu.
Şöyle düşünün. Apache veya e-devlette de halen kullanılmakta olan Ngix sunucusu standart olarak aynı anda (anlık olarak) 300 paralel işlemi yapar. 300 sayısı ön tanımlıdır bu arttırılabilir yada azaltılabilir. Sunucunuz çok güçlü ise ve çok fazla ziyaret alıyorsanız bu sayıyı arttırabilirsiniz. Lakin şu hesabı yapmanız gerekir. Gelen isteklerin (request) bitirilme bitirilme süresi (proces time) kuyruktaki yığılma (queue) arasındaki dengeyi hesaplayamazsanız sunucunuz doğal olarak çöker.
Bilgisayarınızdan yapılan isteklerin içeriğini taşıyan ağ paketlerinin internetteki sayfaya erişip geri dönüşünün 250-300 milisaniye'den daha az olmayacağını farzedersek bu durumda sunucunun 1 saniye içinde işleyebileceği bağlantı (istek) sayısı 1000 cıvarındadır. Bu durumda eğer saniyede bin kişi bağlanıyorsa yapılan istek/işlemlerin 250-300 milisaniye'yi geçmemesi gerekir. Peki geçerse ne olur? Yığılma olur. Eğer işlem kuyruğunda giderek artan bir yığılma olursa 250-300 milisaniye içinde gerçekleşebilecek bir işlem dakikalar hatta saatler içinde askıda kalabilir.
Peki çözüm önerisi ne?
Bununla ilgili paylaşımları bir kaç gün önce Facebook sayfamda yazmıştım.
Sorgulama yapılması gereken işlemlerde sadece sorgulama yapılmalıdır. Hesaplatma ve üretme işlemi yapılmamalıdır. Yani önceden bütün şecere kayıtları oluşturulup veritabanına kaydedilir. Sorgulama yapıldığında da hemen sorgunun cevabı verilir. Bunun da bir takım dezavantajları yok değil. Veriler statik hale gelir. Verilerin güncellendiği durumlarda çok işlevsel olmayabilir. Bazen cache de kullanılabilir.
Alternatif olarak da şöyle yapılabilir. Kullanıcı istek yaptığında yani örneğimizde olduğu gibi şeceresini görmek istediğinde bu işlem 250-300 milisaniye içinde bitebilecek gibi olmadığından talebi kaydedilir ve hazır olduğunda eposta ile indirme/görüntüleme linki gönderilir.
