Tarayıcı, API ve veritabanı sürelerini doğru ilişkilendirmek
Varsayımsal bir liste isteğinde ölçüm noktaları istek kimliğiyle ilişkilendiriliyor. Böylece iç içe geçen süreler iki kez sayılmıyor.
Yavaş ekran, zamanın nerede kaybedildiğini tek başına göstermez. Hedefli inceleme için geliştirme ve işletim ekipleri aynı görevi, aynı isteği ve açık ölçüm sınırlarını kullanmalıdır.
Aşağıdaki örnek tamamen varsayımsaldır. req-17 kimliği, bütün süreler ve sorgu yapısı kurgusaldır. Müşteri sistemi ölçülmedi.
Somut isteğin sınırını tanımlayın
Örnekte portal 20 satırlık sipariş listesi yükler. İsteğe şu varsayımsal ölçümler aittir:
Ölçüm noktası | Varsayılan süre | Ölçülen kapsam |
|---|---|---|
Tarayıcı | 2400 ms | API kaynağının yüklenmeye başlamasından yanıtın tamamen alınmasına kadar |
API | 2300 ms | İsteğin sunucuda işlenmesi |
Veritabanı erişimi | 2100 ms | Bu işleme sırasında ardışık yürütülen veritabanı çağrılarının toplamı |
Veritabanı süresi sunucu süresinin, o da kaynağın alınma süresinin içindedir. Bunları toplamak aynı zamanı tekrar sayar. Paralel çağrılarda toplam çağrı süresi, geçen süreden daha büyük de olabilir.
Tarayıcı ve sunucunun mutlak başlangıç saatleri uygun ortak zaman temeli olmadan birbirinden çıkarılamaz. Tanımlı süreleri ve aynı istekle izlenebilir eşlemeyi kullanın.
Dikkat çeken bölümü inceleyin
Kurgusal akışta 21 veritabanı çağrısı oluşur: bir liste sorgusu, ardından her satır için bir ayrıntı sorgusu. Bu yapı, tekrarlanan veri erişimini somut inceleme noktası yapar. Yüksek sorgu sayısı tek başına bu yapıyı kanıtlamazdı; burada örneğin açık parçasıdır.
Ekranın gerçekten hangi bilgileri istediğini inceleyin. Sınırları belirlenmiş ortak veri çekme olası bir değişikliktir. Aynı izinli kayıtları getirmelidir. Buradan bütün veriyi dev sorguda toplama sonucu çıkmaz.
Tablodaki tarayıcı süresi kaynağın alınmasıyla biter. Ekranın o anda kullanılabilir olduğunu kanıtlamaz. Sonrasında takılı kalıyorsa işleme, çizim ve diğer kaynaklar ayrıca ele alınmalıdır.
Değişikliği karşılaştırılabilir koşullarda sınayın
Yazılım sürümünü, görevi, veri miktarını, filtreleri ve yetki kapsamını kaydedin. Eşzamanlı yük ve önbellek durumu da buna dahildir. Boş ve önceden dolmuş önbellek farklı sonuç verebilir.
İlgili akışı değişiklik öncesi ve sonrasında uygun koşullarda tekrarlayın. Sürenin yanında sonucun ve erişim sınırlarının doğruluğunu da sınayın. Tek bir çok hızlı istek, genel iyileşme kanıtı değildir.
Teknik ölçümlerin kimlere açıldığı belirlenmelidir; bu not için müşteri içeriği gerekmez. İncelemenin sonucu, kapsamı tanımlı ve gerekçeli sonraki değişikliktir; bütün uygulamanın hızına dair genel hüküm değildir.
Kaynaklar
Devamını okuyun
Tüm yazılar
ASES ile Yazılım geliştirme
Özel yazılım, web ve mobil uygulamalar