POWER BI PERFORMANS OPTİMİZASYONU

OfisData7 dk okuma
Power BI raporunda görsel yükleme sürelerinin ölçümünü ve hızlandırmayı anlatan performans kompozisyonu

Rapor açılıyor, görseller tek tek beliriyor, dilimleyiciye her tıklayışta ekran birkaç saniye donuyor. Toplantıda yönetici bekliyor, sunan kişi "birazdan gelecek" diye dolduruyor. Yavaş rapor yalnızca sabır sorunu değildir — kullanılmayan rapora dönüşmenin ilk adımıdır: insanlar beklemek yerine eski Excel'lerine döner.

İyi haber: Power BI yavaşlığı tahminle değil ölçümle çözdürür. Desktop'a gömülü Performans çözümleyicisi, her görselin kaç milisaniyede yüklendiğini ve sürenin nereye gittiğini raporlar. Bu yazıda ölçümü gerçek bir dosya üzerinde yapıyor, sonra yavaşlığın tipik nedenlerini tek tek ele alıyoruz.

Örnek dosyayı indir (.pbix) — çözümleyiciyle ölçüme hazır

1. Önce Ölç: Performans Çözümleyicisi

Araç, Görüntüle sekmesinde durur: Performans analizi. Panel açılınca akış üç adımdır: Kaydı başlat → Görselleri yenile → sonuçları oku. Yenile komutu sayfadaki her görseli sıfırdan çizdirir ve her birinin süresini kaydeder.

Ölçümün ilk kuralı temsili koşullar: gerçek veri hacmiyle, gerçek kullanım senaryosuyla ölçün. Beş satırlık test verisinde her rapor hızlıdır; sorun, üretim verisinin milyonlarca satırında ortaya çıkar. İkinci kural tekrarlanabilirlik: iyileştirme öncesi ve sonrası aynı sayfada aynı akışla ölçüm alın — "sanki hızlandı" hissi, milisaniye tablosunun yerini tutmaz.

2. Süre Listesi Nasıl Okunur

Örnek dosyada kayıt başlatıp sayfayı yenilediğimizde panel şu tabloyu üretti:

Performans çözümleyicisi paneli: bölge grafiği 238 ms, gösterge 232 ms, metin kutusu 44 ms süre kayıtları

Üç görsel, üç süre: bölge grafiği 238 ms, hedef göstergesi 232 ms, metin kutusu 44 ms. Küçük modelde bu değerler zaten sağlıklı (göz, ~200 ms altını anlık algılar; 1-2 saniye kabul edilebilir sınırdır; onun üstü kullanıcının hissettiği beklemedir). Okumanın püf noktası sıralamadır: listeyi süreye göre büyükten küçüğe sıralayın ve en tepedeki bir-iki görsele odaklanın — toplam yavaşlığın çoğu genellikle tek görselden gelir.

3. DAX Sorgusu ve Görüntü Ayrımı

Listedeki her görselin yanındaki artı işareti, süreyi bileşenlerine ayırır: DAX sorgusu (verinin modelden çekilmesi), Görüntü (görselin çizimi) ve Diğer (sıra bekleme). Bu kırılım, tedaviyi belirler:

  • DAX sorgusu yüksekse sorun hesaptadır: ağır ölçü, satır satır çalışan yinelemeler, kötü model ilişkileri. Çare ölçüyü sadeleştirmek ve modeli düzeltmektir.
  • Görüntü yüksekse sorun çizimdedir: binlerce noktalı dağılım, yüzlerce satırlı tablo. Çare veriyi görselde azaltmaktır — ilk 20, gruplama, sayfalama.
  • Diğer yüksekse görsel kendi başına masum, sayfa kalabalıktır: onlarca görsel sırada bekleşiyordur. Çare sayfayı bölmektir.

Panel her ölçümün DAX sorgusunu kopyalamaya da izin verir — derin analiz gerektiğinde sorgu, DAX Studio gibi araçlara taşınır. Çözümleyicinin tüm yetenekleri için resmî dokümantasyonun performans başlıkları kapsamlı kaynaktır.

4. Yavaşlığın Tipik Nedenleri

Sahada aynı şüpheliler tekrar eder:

  • Tek sayfada görsel enflasyonu: 20+ görsel, her etkileşimde 20+ sorgu demektir. Yönetim sayfası 6 görseli geçmemeli; detay ayrı sayfaya.
  • Gereksiz kolon ve satır yükü: modele "belki lazım olur" diye alınan kolonlar belleği şişirir. Kullanılmayan kolonlar Power Query'de kaldırılmalı.
  • Hesaplanmış kolon bolluğu: ölçüyle yapılabilecek işlerin kolonlaşması hem modeli büyütür hem esnekliği öldürür.
  • Çift yönlü ilişkiler: her filtre etkileşimini pahalılaştırır; yıldız şemadan sapmanın performans faturasıdır.
  • Kart kalabalığı: her kart ayrı sorgudur; sekiz karta bölünmüş bilgi, tek çok satırlı kartta birleşebilir.

5. İyileştirme Öncelik Sırası

Kaynak sınırlıysa kazancın büyükten küçüğe sırası genelde şöyledir: önce model (gereksiz kolonları at, yıldız şemaya dön, çift yönü kaldır), sonra ölçüler (ağır DAX'ı sadeleştir), sonra sayfa (görsel sayısını azalt), en son görsel içi ayarlar (ilk N, gruplama). Sık yapılan hata bu sırayı tersinden yürütmektir — görsellerle oynayarak model borcunu kapatmaya çalışmak, semptom tedavisidir.

Ve döngü ölçümle kapanır: her değişiklikten sonra çözümleyiciyle aynı ölçümü tekrarlayıp milisaniye tablosunu karşılaştırın. Performans işi bittiğinde elinizde "hızlandı" cümlesi değil, öncesi-sonrası süre tablosu olmalı.

6. Dosyayı İndirin

Örnek dosyayı indir (.pbix) — çözümleyiciyle ölçüme hazır

Dosyayı ücretsiz Power BI Desktop ile açın (veri gömülü, indiği anda çalışır) ve ölçümü kendiniz yapın: Görüntüle > Performans analizi > Kaydı başlat > Görselleri yenile. Süreleriniz bizimkinden farklı çıkacaktır — donanıma göre değişir; önemli olan mutlak sayı değil, görseller arası oran ve artı işaretinin altındaki kırılımdır. Dilimleyici etkileşimlerini de kayıt altındayken deneyin: her tıklamanın maliyeti listeye düşer.

Performans, model tasarımının aynasıdır: yıldız şema düzgünse çözümleyici çoğu zaman yeşil tablo verir. Büyük veri hacimlerinde ölçüm, model ayarları ve artımlı yenileme stratejilerini birlikte çalışmak isteyenler için Power BI eğitimi performans başlığını gerçek senaryolarla işliyor.

Sıkça Sorulan Sorular

Raporumuz Desktop'ta hızlı ama tarayıcıda (hizmette) yavaş; neden?

İki ortamın darboğazı farklıdır: Desktop yerel makinenizin gücünü kullanır; hizmette kapasite, eş zamanlı kullanıcılar ve ağ devreye girer. Yine de ilk adım aynıdır — Desktop'ta çözümleyiciyle ölçün: görsel süreleri orada da yüksekse sorun rapordadır ve tasarım iyileştirmesi iki ortamı birden hızlandırır. Desktop temiz, hizmet yavaşsa kapasite ve ağ tarafına bakılır.

Kaç milisaniye 'yavaş' sayılır; kurumsal bir eşik koymalı mıyız?

Pratik eşikler: görsel başına 1 saniyeye kadar rahat, 1-3 saniye izlenmeli, 3 saniye üstü müdahale gerektirir. Kurumsal standart olarak 'özet sayfa toplamı 5 saniyede tam yüklenir' gibi kullanıcı odaklı tek hedef koymak, görsel bazlı mikro eşiklerden daha işlevseldir. Eşik ne olursa olsun, ölçüm koşulları (veri hacmi, sayfa) sabitlenmeden karşılaştırma yapılmamalıdır.

Milyonlarca satırlık tabloyla çalışıyoruz; içe aktarma modu yeterli mi?

Çoğu zaman evet — içe aktarma modu sıkıştırılmış çalışır ve milyonlarca satırda da hızlıdır; asıl belirleyici satır sayısından çok kolon sayısı ve kardinalitedir. Gereksiz kolonları atmak çoğu 'büyük veri' sorununu çözer. Veri bellek sınırlarını gerçekten zorluyorsa DirectQuery ve artımlı yenileme seçenekleri gündeme gelir; bunlar da kendi performans kurallarını getirir.

Tek kişilik kullanımda performansla uğraşmaya değer mi?

Rapor yalnız sizin için bile olsa iki durumda değer: dilimleyici tıklamaları hissedilir gecikiyorsa (analiz akışınızı bozar) ve dosya büyüyüp açılışı yavaşlatıyorsa. İlaç genelde aynıdır: kullanılmayan kolonları kaldırmak. Beş dakikalık çözümleyici ölçümü, nereye bakacağınızı tahminden kurtarır.