Gün sonu kapanışta kilitlenen, ay sonu raporu bir türlü açılmayan, birkaç kullanıcı aynı anda girdiğinde duran sistemlerin nedenini ölçerek buluruz. Tahminle değil, sorgu planı ve profil verisiyle; önceki ve sonraki durumu aynı düzenekle ölçerek.
Sistem yavaşlığı, geç fark edilen ve fark edildiğinde çoğu zaman tek bir nedene indirgenemeyen sorunlardan biridir. Program ilk kurulduğunda hızlı çalışır; veri büyüdükçe, kullanıcı sayısı arttıkça ve yıllar içinde yeni ekranlar eklendikçe önce belli saatlerde, sonra sürekli olarak ağırlaşır. Tipik tablo şudur: gündüz kabul edilebilir çalışan sistem gün sonu kapanışta kilitlenir, ay sonu raporu açılmayı bekletir, birkaç kullanıcı aynı anda aynı ekrana girdiğinde herkes birden durur. Bunlar farklı arızalar gibi görünür; çoğu zaman aynı kökten gelir. Bu sayfa sunucu, veritabanı ve uygulamanın veri erişim katmanındaki yavaşlığı konu alır; tarayıcı tarafındaki yükleme hızı ve Core Web Vitals çalışması ayrı bir başlıktır ve PWA ile web performansı sayfasında anlatılır.
Bu noktada en sık başvurulan çözüm, sunucuyu büyütmektir. Daha fazla çekirdek, daha fazla bellek, daha hızlı disk. Donanım, gerçekten kapasiteye dayanmış bir sistemde işe yarar. Ancak darboğaz kötü giden bir sorgu planı, eksik ya da yanlış tasarlanmış bir indeks, bir kaydı çekmek için döngü içinde defalarca veritabanına gidilmesi, tek bir uzun işlemin diğer herkesi bekletmesi ya da ağır raporlamanın canlı üretim veritabanının üstünde koşması ise, daha güçlü sunucu aynı işi bir süre daha taşır ama nedeni ortadan kaldırmaz. Hangisi olduğu ancak ölçümle ayrılır; ölçmeden yapılan müdahale iyileştirme değil tahmindir.
Pan Innovation House olarak bu işe bir vaatle değil, bir yöntemle giriyoruz. Önce mevcut durumu ölçer, hangi işlemin ne kadar sürdüğünü ve zamanın nerede kaybedildiğini ölçümle ortaya koyarız; darboğazları etki büyüklüğüne göre sıralar, her düzeltmeyi tek tek uygular ve aynı ölçüm düzeneğiyle yeniden ölçeriz. İş, sabit süreli ve sabit kapsamlı bir teşhis çalışmasıyla başlar; kapsam ve süre başlamadan önce yazılı olarak belirlenir. Düzeltme ayrı bir kalemdir ve ancak teşhis elinizde olduktan sonra, ne kadar iş olduğunu bilerek karar verirsiniz.
Bu sayfada anlatılan işin dayanağı bir hız rekoru değil, çözümleme derinliğidir. Derlenmiş bir kurumsal uygulamanın veri erişim katmanını çözümledik: ORM kullanılmadığını, erişimin doğrudan ADO.NET ile yapıldığını kanıtlarıyla ortaya koyduk ve kaynağı bulunamayan altmışın üzerinde veritabanı nesnesinin çağrı sözleşmesini kanıtıyla çıkardık, bir bölümünün gövdesini de çağrıldıkları yerlerden ve kodun okuduğu çıktı kolonlarından yola çıkarak yeniden kurduk. Bu çalışma, sözleşme ile gövdenin ayrı ele alındığı ikinci sürümünde ayrı bir karşı-okuma turundan geçirildi: her iddia kanıtıyla tek tek sınandı, dayanağı yetersiz bulunanlar geri çekildi, ulaşılamayan ve doğrulanamayan noktalar raporda açıkça işaretlendi. Bir sistemin yavaşlığını bulmak da tam olarak bu kası ister: kodun ve veritabanının içinde gerçekte ne olduğunu görebilmek.
Gaziantep ve çevre organize sanayi bölgelerinde halı, tekstil, gıda, plastik ve makine üreten işletmeler. Logo, Mikro, Netsis, Canias veya SAP kurulu; sistem yıllar içinde büyüdü ve artık gün sonu kapanışta, sayım döneminde ya da yoğun sipariş girişinde tıkanıyor. Teşhis, ERP'yi değiştirmeden, yanındaki katmanda ve veri tarafında yürütülebilir.
Kesim, sipariş, hakediş veya üretim takibi yıllar önce yazdırılmış özel bir programla yürüyen firmalar. Program çalışıyor ama gitgide yavaşlıyor ve içinde ne olduğunu kimse bilmiyor. Bu durumda performans teşhisi, aynı zamanda sistemin nasıl çalıştığının çıkarılması demektir.
Karar için beklenen raporun uzun süre açılmadığı, açılırken de başka kullanıcıları yavaşlattığı işletmeler. Buradaki mesele genellikle raporun kendisi değil, raporlama yükünün operasyonel veritabanının üstünde çalışıyor olmasıdır.
Bayi portalı, sipariş ekranı veya saha uygulaması gibi aynı anda birden çok kişinin kullandığı sistemlerde, kullanıcı sayısı arttıkça herkesin birden beklemeye başladığı yapılar. Kilitlenme, blocking ve bağlantı havuzu tükenmesi bu tablonun en yaygın nedenleridir.
| Yetenek | Ne sağlar |
|---|---|
| Yavaş sorgu profilleme ve iş yükü envanteri | Sistemin gerçek yükünü ölçeriz: hangi sorgular en çok toplam süreyi tüketiyor, hangileri en çok çağrılıyor, en çok okuma hangi işlemde yapılıyor. Tek tek şikâyet edilen ekranlar yerine ölçülmüş bir iş yükü listesi çıkarır, zamanın nerede kaybedildiğini ölçümle gösteririz. Bu aşama salt okunur yürütülür; sisteme bir değişiklik yapılmaz. |
| Sorgu planı ve indeks stratejisi | Kritik sorguların çalıştırma planlarını inceler; tarama ile arama farkını, tahmini ve gerçekleşen satır sayıları arasındaki sapmayı, sıralama ve birleştirme maliyetlerini ortaya koyarız. İndeks önerileri gelişigüzel eklenmez; her indeksin yazma tarafına getireceği maliyet, mevcut indekslerle örtüşmesi ve gerçekten kullanılıp kullanılmadığı ayrıca değerlendirilir. Veritabanı tarafındaki her değişiklik önce yazılı öneri olarak sunulur; ERP tedarikçinizin destek kapsamını etkileyebilecek maddeler ayrı başlık altında işaretlenir. |
| Kilitlenme, blocking ve eş zamanlılık analizi | Kimin kimi beklettiğini çıkarırız: uzun süren işlemler, geniş tutulan kilitler, gereksiz sıkı yalıtım seviyeleri ve karşılıklı kilitlenmeler. Tek kullanıcıyla hızlı görünen, kullanıcı sayısı arttıkça duran sistemlerin nedeni çoğunlukla burada saklıdır ve ancak eş zamanlı yük altında ölçülerek görülebilir. Bu ölçüm, canlı ortamda değil kopya ortamda veya sizinle kararlaştırılmış bir pencerede yapılır. |
| Veri erişim katmanı temizliği | Uygulama tarafında döngü içinde tekrar tekrar veritabanına gidilmesi (N+1), gerekmeyen sütunların ve satırların çekilmesi, sayfalama yapılmadan tüm tablonun belleğe alınması, bağlantı havuzunun yanlış yapılandırılması ve kapatılmayan bağlantılar gibi sorunları tespit ederiz. Bu katman, veritabanı ne kadar iyi ayarlanırsa ayarlansın yavaşlığı geri getirebilir. |
| Raporlama yükünün operasyondan ayrılması | Ağır raporların canlı üretim veritabanı üzerinde koşması, hem raporu yavaşlatır hem operasyonu kilitler. Raporlama yükünü ayrı bir okuma kopyasına, özetlenmiş tablolara veya ayrı bir raporlama katmanına taşıyacak yapıyı tasarlarız. Bu yapı ERP'nin yerine geçmez, yanında kurulur; hangi metriğin ne sıklıkta tazeleneceğini birlikte belirleriz. |
| Ölçüm düzeneği ve regresyon koruması | Öncesi ve sonrası aynı koşullarda karşılaştırılabilsin diye tekrar edilebilir bir ölçüm düzeneği kurarız. Düzeltmeler yapıldıktan sonra kazanımın zamanla erimemesi için eşik ve izleme önerileri bırakır; yeni geliştirmelerin performansı geriye götürüp götürmediğinin nasıl yakalanacağını yazılı hale getiririz. |
Önce neyin yavaş olduğunu sizin ağzınızdan netleştiririz: hangi ekran, hangi rapor, günün hangi saatinde, kaç kullanıcıyla. Ardından bu şikâyetleri ölçülebilir hale getiririz. Tekrar edilebilir bir ölçüm düzeneği kurulur, başlangıç değerleri kaydedilir ve hangi ölçümün ne zaman çalışacağı önceden sizinle kararlaştırılır. Bu kayıt, çalışmanın sonunda karşılaştıracağımız referans noktasıdır; olmadan hiçbir iyileşme gösterilemez.
Sistem gerçek yükü altındayken profillenir. Sorgu planları, bekleme istatistikleri, kilit ve blocking kayıtları ile uygulama tarafındaki veri erişim çağrıları birlikte incelenir. Teşhis aşaması salt okunur yürütülür; ERP'nin kendisine bu aşamada hiçbir değişiklik yapılmaz. Amaç semptomu değil kaynağı bulmaktır: aynı yavaşlık bazen indeks eksikliğinden, bazen döngü içindeki sorgudan, bazen tek bir uzun işlemin herkesi bekletmesinden gelir. Her bulgu, dayandığı ölçümle birlikte kaydedilir; tahmin, kesin bilgi gibi sunulmaz.
Sabit süreli ve sabit kapsamlı çalışmanın çıktısı yazılı bir teşhis raporudur: ölçülmüş başlangıç durumu, bulunan darboğazlar, her birinin tahmini etkisi ve çözüm için gereken iş büyüklüğü. Bulgular etki ve maliyet ekseninde sıralanır; hangisinin ERP'ye hiç değişiklik yapılmadan çözülebileceği, hangisinin veritabanı tarafında değişiklik gerektirdiği ve bunlardan hangilerinin ERP tedarikçinizin onayını gerektirdiği ayrı ayrı listelenir. Bu noktada düzeltmeye devam edip etmemek sizin kararınızdır.
Onaylanan düzeltmeler topluca değil, birer birer uygulanır. Aynı anda beş değişiklik yapılırsa hangisinin işe yaradığı, hangisinin başka bir yeri bozduğu asla bilinemez. Her müdahale önce kopya ortamda denenir, Pan Standard çift göz onayından geçer, canlıya yalnızca sizin onayınızla ve önceden konuşulmuş bakım penceresinde alınır; geri dönüş yolu her adımda açık tutulur.
Her düzeltmeden sonra, birinci adımdaki düzeneğin aynısıyla yeniden ölçüm yapılır. Önceki ve sonraki değerler yan yana raporlanır; beklenen kazanımı vermeyen bir değişiklik kazanç gibi gösterilmez, gerekirse geri alınır. Çalışma; eşikler, izleme önerileri ve bakım kapsamıyla kapatılır. Teşhis raporu, ölçüm düzeneği ve yazılan her satır kod yüzde yüz size aittir.
Hayır. Sisteminize bakmadan bir hızlanma rakamı söylemek, ölçüm yerine tahmin satmaktır. Yavaşlığın nedeni sisteme bakmadan bilinemez; kimi durumda tek bir indeks tabloyu değiştirir, kimi durumda sorun uygulamanın veri erişim biçiminde olduğu için daha derin bir çalışma gerekir. Bizim taahhüdümüz sonuçla değil yöntemle ilgilidir: başlangıç durumunu ölçer, darboğazları kanıtıyla gösterir, yapılan her değişikliğin etkisini aynı düzenekle yeniden ölçeriz.
Dürüst cevap: pazarlama malzemesi yaptığımız bir performans iyileştirme vakası öne sürmüyoruz. Öne sürdüğümüz şey, bu işin gerektirdiği çözümleme derinliğidir. Derlenmiş bir kurumsal uygulamanın veri erişim katmanını çözümledik; ORM kullanılmadığını, erişimin doğrudan ADO.NET ile yapıldığını ortaya koyduk ve kaynağı bulunamayan altmışın üzerinde veritabanı nesnesinin çağrı sözleşmesini kanıtıyla çıkardık, bir bölümünün gövdesini de yeniden kurduk. Bu çalışma, ikinci sürümünde ayrı bir karşı-okuma turundan geçirildi: her iddia kanıtıyla sınandı, dayanağı yetersiz olanlar geri çekildi, ulaşılamayan noktalar raporda işaretlendi. Yavaşlığın kaynağını bulmak aynı kası ister. Sattığımız şey teşhis kabiliyetidir, sonuç garantisi değil.
Mevcut ERP'nizi değiştirmeyiz. Logo, Mikro, Netsis, Canias veya SAP kurulu olsun, sistemi yerinde bırakır, yanındaki katmanda çalışırız; daha önce Netsis'e dokunmadan yanında çalışan bir katman kurduğumuz yaklaşımın aynısıdır. Teşhis aşaması salt okunur yürütülür: iş yükü, sorgu planları ve bekleme istatistikleri okunur, ERP'nin kendisine hiçbir değişiklik yapılmaz. Düzeltme aşamasında veritabanı tarafında bir değişiklik (örneğin bir indeks) gerekiyorsa, bunun ERP tedarikçinizin destek kapsamını etkileyip etkilemediğini önce yazılı olarak belirtir, tedarikçi onayı gereken maddeleri ayrı başlık altında listeleriz. Karar sizindir.
Donanım, gerçekten kapasiteye dayanmış bir sistemde işe yarar. Ama darboğaz kötü bir sorgu planı, eksik indeks, döngü içindeki tekrarlı sorgular ya da birbirini bekleten kilitlerse, daha güçlü sunucu aynı işi bir süre daha taşır ve nedeni ortadan kaldırmaz. Darboğazın işlemcide mi, diskte mi, beklemede mi olduğu tahminle değil bekleme istatistikleriyle değerlendirilir. Ölçüm sonunda donanım gerçekten gerekiyorsa bunu da açıkça söyleriz.
Teşhis, canlı sistemi gözlemleyerek ve kopya ortam üzerinde yürütülür. Canlıda kullanılan ölçüm yöntemleri düşük maliyetli olanlardan seçilir ve hangi ölçümün ne zaman çalışacağı önceden sizinle kararlaştırılır. Eş zamanlı yük testi gerekiyorsa bu, canlıda değil kopya ortamda veya sizinle konuşulmuş bir pencerede yapılır. Canlı ortama yalnızca sizin onayınızla dokunulur; her düzeltmenin geri dönüş yolu önceden hazırlanır.
İsterseniz evet, ancak zorunlu değil. Teşhis raporu, kendi ekibinizin veya mevcut yazılım tedarikçinizin uygulayabileceği kadar açık yazılır: hangi sorgu, hangi plan, hangi öneri, ne gerekçeyle. Teşhis, sabit süreli ve sabit kapsamlı bir çalışmadır; kapsam ve süre başlamadan önce yazılı olarak belirlenir. Düzeltme ayrı bir kalemdir ve iş büyüklüğü artık bilindiği için gerçekçi biçimde fiyatlanır. Raporu alıp yolunuza kendi ekibinizle devam etmeniz bizim için de kabul edilebilir bir sonuçtur.
Bu sık karşılaşılan bir durum ve kapsamı doğrudan etkiler. Kaynak kod yoksa, veritabanı tarafındaki iş yükü ve uygulamanın gönderdiği sorgular üzerinden yine de çok şey görülebilir; hangi ekranın hangi sorguyu ürettiği ve nerede tıkandığı büyük ölçüde çıkarılabilir. Ancak düzeltmenin uygulama içinde yapılması gerekiyorsa, önce programın devralınması gerekir. Bu ayrı bir çalışmadır ve teşhis raporunda açıkça bu şekilde belirtilir.
Ölçülmüş bir başlangıç durumu; darboğazların dayandıkları ölçümlerle ve etki sırasıyla listelendiği yazılı bir teşhis raporu; her bulgu için önerilen çözüm ile tahmini iş büyüklüğü; hangi maddenin ERP tedarikçinizin onayını gerektirdiğinin ayrı listesi ve çalışmayı tekrar edebilmeniz için ölçüm düzeneğinin tarifi. Düzeltme aşamasına geçilirse, her değişikliğin öncesi ve sonrası ölçümüyle birlikte raporlanan bir kayıt. Üretilen her şey, kod dahil, yüzde yüz size aittir.
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
Kritik iş akışlarınızı otomatik testlerle koruruz: kabul kriterlerinin yazılması, uçtan uca senaryolar, regresyon paketi ve sürüm öncesi otomatik koşum. Bir güncellemenin neyi bozduğu, müşteriden değil testten öğrenilir.
Detay →Teslim edilmiş ya da devralınmış uygulamalarda güvenlik denetimi yaparız: yetkilendirme ve veri erişim hataları, kimlik doğrulama zayıflıkları, enjeksiyon riskleri, sır ve anahtar yönetimi, bağımlılık zafiyetleri. Bulguları kapatma tarafında da çalışırız.
Detay →Mevcut yazılım varlığınızı bağımsız olarak değerlendiririz: mimari haritası, teknik borç envanteri ve önceliklendirmesi, bağımlılık ve tedarikçi kilitlenmesi riski, ekibin çalışma biçimi ve gerçekçi bir yol haritası. Kod yazmadan yön veren bir çalışmadır.
Detay →Tek müşteri için yazılmış ve çalışan bir yazılımı satılabilir bir ürüne dönüştürürüz: çekirdek ile müşteriye özel katmanın ayrılması, konfigürasyon motoru, çok kiracılı veri izolasyonu, kurulum ve sürüm yönetimi ile abonelik altyapısı.
Detay →Talep ile tedariğin nerede ayrıştığını, hangi tedarikçinin termininde durduğunu ve malın şu anda hangi noktada beklediğini tek yerden görünür kılarız. Amaç yeni bir ERP kurmak değil; mevcut sistemin bilmediği zincir dışı bilgiyi toplayıp planlama kararını veriye bağlamaktır.
Detay →Talebin nereden geldiğini, hangi tekliflerin alındığını, kimin neyi onayladığını ve gelen faturanın siparişle örtüşüp örtüşmediğini tek bir zincirde toplarız. Satın alma kişilerin hafızasında değil sistemde yürür; her adım geriye dönük olarak gerekçesiyle birlikte okunabilir. Mevcut ERP'niz yerinde kalır.
Detay →
