Teknik rehber
Performans sorunu varsayımlarla değil kanıtla nasıl incelenir?
Performans incelemesi bir ölçüm sorusuyla başlar: hangi işlem, kimin için, hangi koşulda ve ne kadar yavaş? Ardından bir başlangıç çizgisi kurulur, sürenin nereye harcandığı çağrı zinciri boyunca ölçülür ve darboğaz belirtiden ayrılır. Yapılan değişikliğin etkisi, aynı koşullarda yeniden ölçülmeden sonuç olarak yazılmaz.
- Hazırlayan Castintech
- Son doğrulama 23 Eylül 2026
- 9 dk okuma
- Kaynakça
Bu rehberde
Bölümler
Kapsam. Bu rehber, SAP® yazılımı ortamlarında ve özellikle ABAP® programlama diliyle yazılmış özel kodda karşılaşılan performans sorunları için genel bir inceleme yöntemidir. İzleme ve iz sürme araçlarının adları ve kapsamları ürün ve sürüme göre değişir; rehber belirli bir aracı anlatmaz. İlkeler genel mühendislik bilgisidir ve SAP’ye atfedilmez.
Diyagramın metin açıklaması
Başlangıç: belirti; “sistem yavaş” bir gözlemdir, ölçülebilir bir soru değildir. Belirti, beş bilgili bir ölçüm sorusuna çevrilir: işlem veya senaryo, kullanıcı grubu, zaman aralığı, beklenen ve gözlenen süre, iş etkisi. Ardından başlangıç çizgisi tek ölçümle değil, dağılımla kurulur: ortalama, yüzdelik dilim ve en uzun süre işaretli temsilî bir histogram. Çağrı zinciri, süreyi veri tabanı erişimi, uygulama mantığı, dış sistem çağrıları, ağ, kilit ve kaynak beklemeleri ile kullanıcı arayüzü kalemlerine ayırır; bir kalem hipotez kalemi X olarak işaretlidir. Karar noktası 1: darboğaz mı, belirti mi? Hipotez: X azaltılırsa toplam süre kısalmalı; X izole edilerek ölçülür. Doğrulanmazsa kesikli dönüş yolu çağrı zincirine geri gider ve inceleme sonraki kaleme geçer. Doğrulanırsa tek değişiklik yapılır. Ardından aynı koşullarda yeniden ölçülür; bu çerçeve başlangıç çizgisiyle aynı genişlikte ve aynı eksendedir, başlangıç silueti yalnız karşılaştırma için kesikli gösterilir ve yeni bir sonuç çizilmez. İki çerçeveyi bağlayan ayraç aynı koşulları gösterir: eşzamanlı yük ve çalışan toplu işler, veri hacmi ve dağılımı, seçim ölçütleri, önbellek durumu ve aynı protokol. Sınır: test ortamındaki ölçüm yön gösterir, canlı ortamdaki davranışın kanıtı değildir. Karar noktası 2: etki aynı koşullarda kanıtlandı mı? Kanıtlanmadıysa sonuç yazılmaz ve etki hipotez olarak kalır; bu dal burada biter. Bitiş: kanıtlandıysa yeniden üretilebilir kanıt dosyası; ham sonuçlar yorumdan ayrı saklanır ve iki sonucun aynı sayılacağı fark ölçümden önce tanımlanır. Darboğaz hipotezindeki tek dönüş yolu dışında döngü yoktur. Grafik ölçekleri temsilîdir, ölçüm değeri değildir. Mobilde diyagram üç sıralı panelde okunur: 1/3 belirti, ölçüm sorusu ve başlangıç çizgisi, 2/3 bağlam, çağrı zinciri ve darboğaz, 3/3 tek değişiklik, yeniden ölçüm ve kanıt. Künye: Castintech, D4, Eylül 2026; teknik anlatım diyagramı, SAP® ürün arayüzü değildir.
Ölçüm sorusu nasıl kurulur?
“Sistem yavaş” bir gözlemdir, ölçülebilir bir soru değildir. Ölçüm sorusu; işlemi veya senaryoyu, etkilenen kullanıcı grubunu, zaman aralığını, beklenen ve gözlenen süreyi ve iş etkisini içerir. Bu beş bilgi yazılmadan başlayan inceleme, çoğu zaman en kolay ölçülen yere odaklanır; en önemli yere değil.
Ölçüm sorusu şablonu:
| Bilgi | Örnek biçim |
|---|---|
| İşlem veya senaryo | Belirli bir raporun belirli seçim ölçütleriyle çalıştırılması |
| Kullanıcı grubu | Hangi rol veya birim etkileniyor |
| Zaman aralığı | Gün içi hangi saatler, ay içi hangi günler |
| Beklenen ve gözlenen | İşin kabul edebileceği süre ve bugün gözlenen süre |
| İş etkisi | Gecikme hangi iş sonucunu etkiliyor |
Başlangıç çizgisi neden gereklidir?
Başlangıç çizgisi, bugünkü durumun tanımlı koşullarda yapılmış ölçümüdür. O olmadan bir değişikliğin etkisini göstermek mümkün değildir. Çizgi tek bir ölçümle değil, bir dağılımla kurulur: ortalama yanında, işlemlerin büyük çoğunluğunun hangi süre içinde bittiğini gösteren yüzdelik dilimler ve en uzun süreler de kaydedilir.
Ortalama, seyrek ama çok uzun süren işlemleri gizleyebilir. Kullanıcının hissettiği sorun çoğu zaman bu uzun kuyruktadır. Bu nedenle başlangıç çizgisinde hangi istatistiğin kullanıldığı açıkça yazılır ve sonraki ölçümlerde aynı istatistik kullanılır.
Çalışma zamanı ve veri hacmi bağlamı neden kaydedilir?
Aynı işlem, farklı koşullarda farklı sürede çalışır. Ölçüm yapıldığında sistemdeki eşzamanlı yük, çalışan toplu işler, işlenen veri hacmi, verinin dağılımı, kullanılan seçim ölçütleri ve önbelleğin durumu kaydedilmezse iki ölçüm birbiriyle karşılaştırılamaz. Bu bilgiler ölçümün kendisi kadar önemlidir; çünkü sonucun hangi koşulda geçerli olduğunu gösterir.
Veri hacmi özellikle önemlidir. Küçük bir veri kümesinde hızlı çalışan bir işlem, veri büyüdükçe orantısız yavaşlayabilir. Bu yüzden ölçümle birlikte işlenen kayıt sayısı ve seçim ölçütleri de yazılır; aksi hâlde yavaşlığın koddan mı, veriden mi kaynaklandığı ayrılamaz.
Hangi değişkenler ölçümü bozar?
Bazı değişkenler, sorunla ilgisi olmadığı hâlde ölçülen süreyi değiştirir. Bunlar kontrol edilmez veya en azından kaydedilmezse, iki ölçüm arasındaki fark yanlış bir değişikliğe bağlanabilir. Aşağıdaki değişkenler her ölçümde gözden geçirilir; kontrol edilemeyenler ölçüm kaydına not olarak düşülür ve sonuç yorumlanırken hesaba katılır.
- önbelleğin ilk çalıştırmada boş, sonrakilerde dolu olması
- aynı anda çalışan toplu işler, yedeklemeler veya yoğun kullanıcı trafiği
- ölçüm dönemleri arasında verinin hacminin veya dağılımının değişmesi
- farklı yetkilere sahip kullanıcıların farklı miktarda veri görmesi
- ağ gecikmesindeki dalgalanmalar ve karşı sistemlerin o anki durumu
- ölçüm veya iz sürme aracının kendi ek yükü
- ay sonu gibi dönemsel yoğunluklar
Bir değişkenin etkisinden şüpheleniliyorsa, yalnız o değişkeni değiştiren ek bir ölçüm yapılır. Böylece gözlenen farkın ne kadarının bu değişkenden kaynaklandığı ayrı olarak görülebilir.
Kanıt hangi kaynaklardan toplanır?
Tek bir kaynak, performans sorununun tamamını göstermez. Sistem düzeyindeki izleme verisi kaynak kullanımını, iz kayıtları bir işlemin hangi adımda ne kadar süre harcadığını, veri tabanı erişim istatistikleri ise hangi sorguların ne sıklıkla ve ne kadar veriyle çalıştığını gösterir. Uygulama logları ve toplu iş kayıtları zamanlamayı, kullanıcının ölçtüğü süre ise işin gerçekte nasıl hissedildiğini anlatır.
Bu kaynaklar birbirini doğrulamak için birlikte kullanılır. Örneğin iz kaydı bir sorgunun uzun sürdüğünü gösteriyorsa, veri tabanı istatistikleri aynı sorgunun o dönemde ne kadar veri okuduğunu doğrulayabilir. Kaynaklar çelişiyorsa çelişkinin kendisi bir bulgudur ve ölçüm koşulları yeniden kontrol edilir. Hangi aracın bu kaynakları sağladığı ürün ve sürüme göre değişir; kanıt dosyasında her ölçümün hangi kaynaktan alındığı yazılır.
Gerçek ürün ekranı
Ekranı okumak için yatay kaydırın ya da görseli seçip tam boyutta açın.
Ekranda görülen İstek istatistiklerini yakalama uygulamasında “HANA Plan Trace” türünde bir izleme profili: koşul olarak tek bir SQL deyim özeti tanımlı, profil etkin değil, yerel saklama süresi 2 hafta.
Açıkladığı karar Kanıt toplanırken iz tek bir deyimle sınırlandırılır ve saklama süresi baştan belirlenir; böylece ölçüm incelenen soruyla sınırlı kalır ve kanıt dosyasına hangi koşulla alındığı yazılabilir.
Veri durumu Görselde iş verisi yok: profil adı “HANA PLAN TRACE EXAMPLE”, sahip alanı genel “Customer” etiketidir. Görünen deyim özeti bir karma değerdir; sorgu metnini göstermez.
Ürün: SAP BTP, ABAP environment — Capture Request Statistics Kaynak: SAP-docs/btp-cloud-platform © 2021-2023 SAP SE or an SAP affiliate company and https://github.com/sap-docs/btp-cloud-platform contributors Lisans: CC BY 4.0, değiştirilmeden kullanılmıştır
Süre nereye harcanıyor?
Toplam süre, çağrı zinciri boyunca parçalarına ayrılmadan hangi değişikliğin işe yarayacağı bilinemez. Süre genellikle şu kalemlere dağılır: veri tabanı erişimi, uygulama mantığı, dış sistem çağrıları, ağ, kilit ve kaynak beklemeleri ve kullanıcı arayüzü. İnceleme, bu kalemlerin her birine düşen payı ölçer.
ABAP kodunda sık görülen kalıplar da bu ölçümle doğrulanır; tahminle değil. Örneğin döngü içinde tekrarlanan veri tabanı erişimi, gereğinden geniş veri okunması veya aynı verinin defalarca işlenmesi bir sorun kaynağı olabilir. Ancak bir kalıbın kodda bulunması, o sorunun ana darboğaz olduğunu göstermez; bunu ölçüm gösterir.
Darboğaz ile belirti nasıl ayrılır?
Belirti, gözlenen sonuçtur: uzun süre, yüksek işlemci kullanımı, dolmuş bir kuyruk. Darboğaz ise azaltıldığında toplam süreyi gerçekten azaltan kısıttır. Yüksek işlemci kullanımı, verimsiz bir döngünün belirtisi olabilir; ama asıl darboğaz başka bir yerde, örneğin bir dış çağrının beklemesinde olabilir. Belirtiyi azaltmak, darboğazı gidermek anlamına gelmez.
Ayrım bir hipotezle yapılır: “Süre, X kalemi nedeniyle uzuyor; X azaltılırsa toplam süre şu kadar kısalmalı.” Hipotez, X’i izole eden bir ölçümle test edilir. Hipotez doğrulanmazsa darboğaz başka bir yerdedir ve inceleme bir sonraki kaleme geçer.
Ölçüm nasıl tekrarlanabilir kılınır?
Tekrarlanabilir ölçüm, aynı koşullar sağlandığında aynı sonucu veren ölçümdür. Bunun için aynı veri ve aynı seçim ölçütleri kullanılır; ölçüm ya aynı zaman aralığında ya da kontrollü bir yük altında yapılır. Ölçüm birden fazla kez tekrarlanır ve sonuçların dağılımı kaydedilir; tek bir çalıştırma, rastlantısal bir sapmayı sonuç gibi gösterebilir.
Ölçüm protokolü yazılı olur: nasıl başlatıldı, hangi koşullarda, kaç kez, hangi istatistikle özetlendi. Bu protokol, değişiklik sonrası ölçümde aynen uygulanır. Protokol değişirse iki ölçüm karşılaştırılamaz ve bu durum raporda belirtilir.
Kanıt başka bir ekip tarafından nasıl yeniden üretilebilir?
Kanıt, yalnız onu toplayan kişi tarafından tekrarlanabiliyorsa bir karar için yeterince güçlü değildir. Yeniden üretilebilir kanıt, başka bir ekibin aynı adımları izleyerek aynı sonuca ulaşabildiği kanıttır. Bunun için ölçüm adımları, kullanılan veri, ortamın sürümü ve yapılandırması ile sonuçların ham hâli, yorumdan ayrı olarak saklanır.
Yeniden üretimde küçük farklar olağandır. Bu yüzden iki sonucun ne kadar farkla “aynı” kabul edileceği ölçümden önce tanımlanır. Fark bu sınırın dışında kalırsa iki ölçüm arasındaki koşul farkı aranır; sonuç, fark açıklanana kadar karar için kullanılmaz. Ham sonuçların saklanması, yorumun sonradan yeniden değerlendirilebilmesini de sağlar.
Değişiklik öncesi ve sonrası nasıl doğrulanır?
Her seferinde tek bir değişiklik yapılır ve etkisi aynı protokolle ölçülür. Aynı anda birden fazla değişiklik yapıldığında hangisinin işe yaradığı ayrılamaz; biri iyileştirirken diğeri kötüleştirmiş olabilir. Karşılaştırma yalnız ortalamayla değil, başlangıç çizgisindeki aynı dağılım istatistikleriyle yapılır. Sonuç da başlangıç çizgisiyle aynı biçimde raporlanır.
Değişikliğin yan etkileri de kontrol edilir: aynı veriyi kullanan başka işlemler, aynı kaynakları paylaşan toplu işler veya entegrasyonlar etkilenmiş olabilir. Bir işlemi hızlandırıp başka bir işlemi yavaşlatan değişiklik, iş açısından iyileştirme sayılmayabilir.
Ölçülmeyen kazanç neden iddia edilmez?
Tahmini bir iyileşme, ölçülmüş bir iyileşme değildir. “Bu değişiklik süreyi kısaltacaktır” cümlesi bir hipotezdir ve öyle yazılır. Sonuç raporuna yalnız aynı koşullarda ölçülmüş önce ve sonra değerleri girer. Ölçüm yapılamamışsa bu açıkça belirtilir ve sonuç yerine hangi ölçümün yapılabileceği yazılır.
Bu kural yönetim kararlarını korur. Ölçülmemiş bir kazanç, bir sonraki bütçe veya öncelik kararında gerçek bir veri gibi kullanılabilir. Gerçekleşmediğinde ise kararın dayanağı ortadan kalkar.
Ortamlar arasında karşılaştırmanın sınırı nedir?
Test ortamı ile canlı ortam; veri hacmi, veri dağılımı, yapılandırma, eşzamanlı yük ve donanım açısından farklı olabilir. Test ortamındaki ölçüm bir yön gösterir; canlı ortamdaki davranışın kanıtı değildir. Rapor, ölçümün hangi ortamda yapıldığını ve bu ortamın canlı ortamdan nasıl farklılaştığını açıkça yazar.
Canlı ortamda ölçüm gerekiyorsa ölçüm araçlarının ek yükü ve ölçüm penceresi önceden planlanır. Ölçüm, iş sürecini etkilemeyecek biçimde ve ilgili sahiplerin bilgisiyle yapılır.
Kanıt dosyası neleri içerir?
| Alan | İçerik |
|---|---|
| Ölçüm sorusu | İşlem, kullanıcı grubu, zaman aralığı, beklenen ve gözlenen, iş etkisi |
| Ortam ve koşullar | Ortam, eşzamanlı yük, veri hacmi, seçim ölçütleri, önbellek durumu |
| Protokol | Başlatma biçimi, tekrar sayısı, özet istatistikler |
| Başlangıç çizgisi | Dağılım: ortalama, yüzdelik dilimler, en uzun süre |
| Süre dağılımı | Çağrı zinciri boyunca kalemlere göre pay |
| Hipotezler | Test edilen hipotezler ve sonuçları |
| Değişiklik | Yapılan tek değişiklik ve gerekçesi |
| Sonrası ölçüm | Aynı protokolle ölçülen dağılım; yan etki kontrolü |
| Sınırlar | Ölçülemeyenler, ortam farkları, açık varsayımlar |
Sık yapılan yanlış varsayımlar
- “En çok kaynak kullanan işlem sorunun kaynağıdır.” Çok kaynak kullanması, darboğaz olduğunu göstermez; ölçüm, toplam süreye etkisini göstermelidir.
- “Test ortamında hızlıysa canlıda da hızlıdır.” Veri hacmi ve yük farkı, sonucu tamamen değiştirebilir.
- “Ortalama iyileştiyse kullanıcı da iyileşmeyi hisseder.” Uzun kuyruktaki işlemler değişmediyse kullanıcı farkı hissetmeyebilir.
- “Kodda bilinen bir kötü kalıp varsa sorun odur.” Kalıbın varlığı etkisini göstermez; etkisi ölçülür.
- “Birkaç değişikliği birlikte yapmak zaman kazandırır.” Hangisinin işe yaradığı anlaşılamaz; biri diğerinin etkisini gizleyebilir.
Kontrol listesi
- Ölçüm sorusu beş bilgiyle yazıldı
- Başlangıç çizgisi dağılım istatistikleriyle kuruldu
- Ortam, yük, veri hacmi ve seçim ölçütleri kaydedildi
- Ölçümü bozabilecek değişkenler kontrol edildi veya kayda geçirildi
- Süre, çağrı zinciri boyunca kalemlere ayrıldı
- Darboğaz hipotezi yazıldı ve izole bir ölçümle test edildi
- Ölçüm protokolü yazıldı ve birden fazla tekrarla uygulandı
- Ölçüm adımları, veri, ortam bilgisi ve ham sonuçlar başka bir ekibin yeniden üretebileceği biçimde saklandı
- Her seferinde tek değişiklik yapıldı
- Sonrası ölçüm aynı protokolle yapıldı; yan etkiler kontrol edildi
- Ortam farkları ve ölçülemeyenler raporda yazıldı
- Ölçülmemiş kazanç sonuç olarak yazılmadı
Sınır notları
Bu rehber genel mühendislik açıklamasıdır ve belirli bir ürün belgesine dayanmaz. SAP araç adları ve ürüne özgü ayarlar bilinçli olarak anlatılmamıştır; bunlar ürün ve sürüme göre değişir ve ortamınızda doğrulanmalıdır. Belirli bir hızlanma, kaynak kullanımı veya süre sonucu iddia etmiyoruz.
Sık sorulan sorular
Ortalama süre neden yeterli değil?
Ortalama, çok sayıda kısa işlemin arasında seyrek ama çok uzun süren işlemleri gizleyebilir. Kullanıcının şikâyet ettiği gecikme çoğu zaman bu uzun işlemlerdedir. Yüzdelik dilimler ve en uzun süreler bu kısmı görünür kılar.
Kullanıcı şikâyeti tek başına kanıt mıdır?
Şikâyet, incelemenin başlangıç noktasıdır; kanıtı değildir. Şikâyetteki bilgi (hangi işlem, ne zaman, ne kadar) ölçüm sorusuna dönüştürülür ve ölçümle doğrulanır.
Donanım artırmak performans sorununu çözer mi?
Bazı durumlarda süreyi kısaltabilir; ancak darboğaz belirlenmeden yapılan donanım yükseltmesi sorunu gizleyebilir ve veri büyüdükçe sorun geri dönebilir. Karar, darboğazın kaynak yetersizliği mi, yoksa verimsiz bir erişim mi olduğu ölçüldükten sonra verilmelidir.
Canlı ortamda ölçüm yapmak riskli mi?
Ölçüm araçları ek yük yaratabilir. Bu yük, ölçüm penceresi ve kapsamı önceden planlanarak sınırlanır. Ölçüm, ilgili sahiplerin bilgisiyle ve iş sürecini etkilemeyecek bir zamanda yapılır.
İyileştirmenin sonucu yönetime nasıl raporlanmalı?
Aynı protokolle ölçülmüş önce ve sonra dağılımları, ölçümün yapıldığı ortam ve koşullar, yan etki kontrolü ve ölçülemeyenler birlikte raporlanır. Ölçülmeyen bir kazanç rapora sonuç olarak girmez.
Performans incelemesi ne zaman sonlandırılmalı?
İnceleme, ölçüm sorusunda tanımlanan kabul edilebilir süreye ulaşıldığında veya kalan darboğazı gidermenin maliyeti iş etkisini aşmaya başladığında sonlandırılır. Bu karar da kanıtla ve iş sahibiyle birlikte verilir; ulaşılan durum başlangıç çizgisiyle karşılaştırılarak kayda geçirilir.
İlgili sayfalar ve rehberler
- Çalışma yaklaşımımız: ölçülmeyen sonucu neden yazmadığımız
- Entegrasyonlarda hata yönetimi ve güvenli tekrar işleme: entegrasyon gecikmelerinde bekleyen mesaj ve süre izlemesi
- Özel kod envanteri ve teknik borç yaklaşımı: performans bulgularının envanterdeki yeri
- Tüm teknik rehberler
Kaynakça
Bu rehber belirli bir ürün belgesine dayanmaz. İçerik genel mühendislik bilgisi ve Castintech’in inceleme çerçevesidir; SAP’ye atfedilmez. Rehberde dış kaynaklı bir iddia yoktur.
Son doğrulama: 23 Eylül 2026
SAP and ABAP are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.
Bu içerik Castintech tarafından bağımsız olarak hazırlanmıştır.
Bağımsızlık notu
- Castintech, SAP SE ile ortaklık, yetkilendirme, onay veya sponsorluk ilişkisi iddia etmez.
- SAP ve bu sayfada geçen SAP ürün adları, SAP SE’nin veya iştiraklerinin ticari markalarıdır.
- Castintech’in sunduğu çalışma, bağımsız teknik danışmanlık ve destek kapsamındadır.