Microsoft Power BI Premium kapasitelerini iyileştirme - Power BI | Microsoft Docs
Premium kapasiteleri iyileştirmeOptimizing Premium capacities
Okumak için 17 dakika
Premium kapasite performans sorunları ortaya çıktığında yeniden kabul edilebilir yanıt sürelerine dönmek için uygulanan yaygın ilk yaklaşımlardan biri çözümlerinizi iyileştirmek veya ayarlamaktır.When Premium capacity performance issues arise, a common first approach is to optimize or tune your solutions to restore acceptable response times. Gerekçe ise, geçerli bir sebep olmadığı sürece ek Premium kapasite satın almaktan kaçınmadır.The rationale being to avoid purchasing additional Premium capacity unless justified.
Ek Premium kapasite gerektiğinde, bu makalede tanımlanan iki seçenek bulunur:When additional Premium capacity is required, there are two options described in this article:
Mevcut Premium kapasiteyi ölçeklendirmeScale-up an existing Premium capacity
Yeni bir Premium kapasite eklemeAdd a new Premium capacity
Son olarak, yaklaşımlar ve Premium kapasite boyutlandırması test edilerek bu makale sonlandırılır.Finally, testing approaches and Premium capacity sizing conclude this article.
En uygun kullanımı ve en iyi performansı elde etmek için şunları da içeren önerilen en iyi yöntemler bulunur:When trying to get the best utilization and performance, there are some recommended best practices, including:
Kişisel çalışma alanlarının yerine çalışma alanlarını kullanma.Using workspaces instead of personal workspaces.
İş açısından kritik ve Self Servis BI’ı (SSBI) farklı kapasitelere ayırma.Separating business critical and Self-Service BI (SSBI) into different capacities.
İçeriği yalnızca Power BI Pro kullanıcılarıyla paylaşıyorsanız bunu bir ayrılmış kapasitede depolamaya gerek kalmayabilir.If sharing content only with Power BI Pro users, there may be no need to store the content in a dedicated capacity.
Belirli bir yenileme zamanına ulaşmak istiyorsanız veya belirli özellikler gerektiğinde ayrılmış kapasiteleri kullanın.Use dedicated capacities when looking to achieve a specific refresh time, or when specific features are required. Örneğin, büyük veri kümeleri veya sayfalandırılmış raporlama ile bunu yapabilirsiniz.For example, with large datasets or paginated reporting.
Sık sorulan soruları ele almaAddressing common questions
Power BI Premium dağıtımlarını iyileştirme karmaşık bir konudur. Bu iyileştirmenin sağlanması için iş yükü gereksinimleri, kullanılabilen kaynaklar ve bunların etkili bir şekilde kullanılması hakkında bilgi sahibi olmak gerekir.Optimizing Power BI Premium deployments is a complex subject involving an understanding of workload requirements, available resources, and their effective use.
Bu makalede, sıkça sorulan destek sorularından yedisi ele alınır, olası sorunlar tanımlanıp açıklamalar sağlanır ve bu sorunların nasıl belirlenip çözüleceğine yönelik bilgiler sunulur.This article addresses seven common support questions, describing possible issues and explanations, and information on how to identify and resolve them.
Kapasite neden yavaşladı? Bununla ilgili ne yapabilirim?Why is the capacity slow, and what can I do?
Premium kapasitenin yavaşlamasına katkıda bulunabilen birçok sebep vardır.There are many reasons that can contribute to a slow Premium capacity. “Yavaş” dendiğinde neyin kastedildiğini anlamak için bu soruyla ilgili daha fazla bilgi gerekir.This question requires further information to understand what is meant by slow. Raporlar yavaş mı yükleniyor?Are reports slow to load? Yoksa yükleme başarısız mı oluyor?Or are they failing to load? Rapor görselleri yavaş mı yükleniyor veya kullanıcılar raporla etkileşime geçtiğinde mi güncelleştiriliyor?Are report visuals slow to load or update when users interact with the report? Yenilemelerin tamamlanması beklenenden veya öncekinden daha uzun mu sürüyor?Are refreshed taking longer to complete than expected, or previously experienced?
Sebepleri anladıktan sonra araştırmaya başlayabilirsiniz.Having gained an understanding of the reason, you can then begin to investigate. Aşağıdaki altı soruya verdiğiniz cevaplar daha özel soruları ele almanıza yardımcı olur.Responses to the following six questions will help you to address more specific issues.
Kapasitemi hangi içerikler kullanıyor?What content is using up my capacity?
Kapasiteye göre filtrelemek ve çalışma alanı içeriği için performans ölçümlerini gözden geçirmek için Power BI Premium Kapasite Ölçümleri uygulamasını kullanabilirsiniz.You can use the Power BI Premium Capacity Metrics app to filter by capacity, and review performance metrics for workspace content. Bir Premium kapasitede depolanan tüm içerikler için performans ölçümlerini ve kaynak kullanımını saate göre gözden geçirme olanağı bulunur.It's possible to review the performance metrics and resource usage by hour for the past seven days for all content stored within a Premium capacity. Premium kapasite performansı hakkında genel bir sorun giderilirken genelde öncelikle izleme adımından başlanır.Monitoring is often the first step to take when troubleshooting a general concern about Premium capacity performance.
İzlenecek ana ölçümler şunları içerir:Key metrics to monitor include:
Ortalama CPU ve yüksek kullanım sayısı.Average CPU and high utilization count.
Ortalama Bellek ve yüksek kullanım sayısının yanı sıra belirli veri kümeleri, veri akışları ve sayfalandırılmış raporlar için bellek kullanımı.Average Memory and high utilization count, and memory usage for specific datasets, dataflows, and paginated reports.
Bellekte yüklenen etkin veri kümeleri.Active datasets loaded in memory.
Ortalama ve en fazla sorgu süreleri.Average and maximum query durations.
Ortalama sorgu bekleme süreleri.Average query wait times.
Ortalama veri kümesi ve veri akışı yenileme süreleri.Average dataset and dataflow refresh times.
Power BI Premium Kapasite Ölçümleri uygulamasında, son üç dakika içinde kullanıldığı için çıkarılamayan bir rapora verilen toplam bellek miktarını gösteren ölçüm etkin bellektir.In the Power BI Premium Capacity Metrics app, active memory shows the total amount of memory given to a report that cannot be evicted because it has been in use within the last three minutes. Yenileme süresindeki ani bir artış büyük ve/veya etkin bir veri kümesi ile bağıntılı olabilir.A high spike in refresh wait time could be correlated with a large and/or active dataset.
Ortalama Süreye Göre En İyi 5 grafiği, kapasite kaynaklarını tüketen en iyi 5 veri kümesini, sayfalandırılmış raporu ve veri akışlarını gösterir.The Top 5 by Average Duration chart highlights the top five datasets, paginated reports, and dataflows consuming capacity resources. En iyi beş listelerindeki içeriklere araştırma ve olası iyileştirmeler için başvurulabilir.Content in the top five lists is candidates for investigation and possible optimization.
Raporlar neden yavaş?Why are reports slow?
Aşağıdaki tablolar olası sorunları ve bunları tanımlayıp düzeltmeye yönelik yöntemleri gösterir.The following tables show possible issues and ways to identify and handle them.
Yetersiz kapasite kaynaklarıInsufficient capacity resources
Olası AçıklamalarPossible Explanations
Nasıl Tanımlanır?How to Identify
Nasıl Çözülür?How to Resolve
Yüksek toplam etkin bellek (model, son üç dakika içinde kullanıldığı için çıkarılamaz).High total active memory (model can't be evicted because it's in use within the last three minutes).
Sorgu bekleme sürelerinde birden fazla, yüksek ani artış.Multiple high spikes in query wait times.
Yenileme bekleme sürelerinde birden fazla, yüksek ani artış.Multiple high spikes in refresh wait times. Bellek ölçümlerini  ve çıkarma ölçümlerini  izleyin.Monitor memory metrics , and eviction counts . Model boyutunu azaltın veya DirectQuery moduna dönüştürün.Decrease the model size, or convert to DirectQuery mode. Bu makalenin Modelleri iyileştirme kısmına bakın.See the Optimizing models section in this article.
Kapasitenin ölçeğini artırın.Scale-up the capacity.
İçeriği farklı bir kapasiteye atayın.Assign the content to a different capacity.
Verimsiz rapor tasarımlarıInefficient report designs
Rapor sayfaları çok fazla görsel içerir (etkileşimli filtreleme, görsel başına en az bir sorgu tetikleyebilir).Report pages contain too many visuals (interactive filtering can trigger at least one query per visual).
Görseller gerekenden daha fazla veri alır.Visuals retrieve more data than necessary. Rapor tasarımlarını gözden geçirin.Review report designs.
Raporlarla nasıl etkileşime geçtiklerini anlamak için rapor kullanıcılarıyla görüşün.Interview report users to understand how they interact with the reports.
Veri kümesi sorgu ölçümlerini izleyin .Monitor dataset query metrics . Raporları, her sayfada daha az görsel olacak şekilde yeniden tasarlayın.Redesign reports with fewer visuals per page.
Özellikle daha önceden raporların performansı iyi olduğunda veri kümesi çok yavaş kalıyorDataset is slow, especially when reports have previously performed well
Hacmi gittikçe artan içeri aktarma verileri.Increasingly large volumes of import data.
RLS rolleri de dahil olmak üzere karmaşık veya verimsiz hesaplama mantığı.Complex or inefficient calculation logic, including RLS roles.
Model tamamen iyileştirilmemiş.Model not fully optimized.
(DQ/LC) Ağ geçidi gecikme süresi.(DQ/LC) Gateway latency.
Yavaş DQ kaynak sorgusu yanıt süreleri.Slow DQ source query response times. Model tasarımlarını gözden geçirin.Review model designs.
Ağ geçidi performans sayaçlarını izleyin.Monitor gateway performance counters. Bu makalenin Modelleri iyileştirme kısmına bakın.See the Optimizing models section in this article.
Yüksek eşzamanlı rapor kullanımıHigh concurrent report usage
Yüksek sorgu bekleme süreleri.High query wait times.
CPU doygunluğu.CPU saturation.
DQ/LC bağlantı sınırları aşıldı.DQ/LC connection limits exceeded. CPU kullanımını , sorgu bekleme sürelerini, ve DQ/LC kullanımı  ölçümlerini + Sorgu sürelerini izleyin.Monitor CPU utilization , query wait times, and DQ/LC utilization  metrics + Query durations. Bunlarda yaşanan dalgalanmalar eşzamanlılık sorunlarına işaret eder.If fluctuating, can indicate concurrency issues. Kapasitenin ölçeğini artırın, veya içeriği farklı bir kapasiteye atayın.Scale-up the capacity, or assign the content to a different capacity.
Raporları, her sayfada daha az görsel olacak şekilde yeniden tasarlayın.Redesign reports with fewer visuals per page.
 Ortalama Bellek Kullanımı (GB), ve En Yüksek Bellek Tüketimi (GB). Average Memory Usage (GB), and Highest Memory Consumption (GB).
 Veri kümesi çıkarmaları. Dataset evictions.
 Veri Kümesi Sorguları, Veri Kümesi Ortalama Sorgu Süresi (ms), Veri Kümesi Bekleme Sayısı ve Veri Kümesi Ortalama Bekleme Süresi (ms). Dataset Queries, Dataset Average Query Duration (ms), Dataset Wait Count, and Dataset Average Wait Time (ms).
 CPU Yüksek Kullanım Sayısı ve CPU’nun En Yüksek Kullanım Zamanı (son yedi gün içerisinde). CPU High Utilization Count and CPU Time of Highest Utilization (past seven days).
 DQ/LC Yüksek Kullanım Sayısı ve DQ/LC’nin En Yüksek Kullanım Zamanı (son yedi gün içerisinde). DQ/LC High Utilization Count and DQ/LC Time of Highest Utilization (past seven days).
Raporlar neden yüklenmiyor?Why are reports not loading?
Raporların yüklenememesi, kapasitenin yetersiz belleğe sahip olduğuna ve aşırı ısındığına işaret eder.When reports fail to load, it's a sure sign the capacity has insufficient memory and is over-heated. Bu, yüklenen tüm modeller aktif olarak sorgulandıkları için çıkarılamadığında ve tüm yenileme işlemleri durdurulduğunda veya geciktiğinde ortaya çıkabilir.This can occur when all loaded models are being actively queried and so cannot be evicted, and any refresh operations have been paused or delayed. Power BI hizmeti, 30 saniye boyunca veri kümesini yüklemeye çalışır. Bu işlem başarısız olursa durum kullanıcıya bildirilir ve kısa bir süre sonra tekrar denemesi önerilir.The Power BI service will attempt to load the dataset for 30 seconds, and the user is gracefully notified of the failure with a suggestion to try again shortly.
Şu anda, rapor yükleme hatalarını izlemeye yönelik bir ölçüm bulunmamaktadır.Currently there is no metric to monitor for report loading failures. Bu soruna yol açan etmenleri sistem belleğini, özellikle de en yüksek kullanım oranına ve en yüksek kullanım süresine sahip olanları izleyerek tanımlayabilirsiniz.You can identify the potential for this issue by monitoring system memory, specifically highest utilization and time of highest utilization. Yüksek veri kümesi çıkarmaları ve veri kümesi yenilemeleri için ortalama bekleme süresinin uzun olması bu sorunun meydana geldiğini gösterebilir.High dataset evictions and long dataset refresh average wait time could suggest that this issue is occurring.
Bu çok nadiren yaşanıyorsa öncelikli bir sorun olarak kabul edilmeyebilir.If this happens only very occasionally, this may not be considered a priority issue. Rapor kullanıcılarına hizmetin meşgul olduğu ve kısa bir süre sonra yeniden denemeleri gerektiği bildirilir.Report users are informed that the service is busy and that they should retry after a short time. Bu çok sık yaşanırsa Premium kapasitesinin ölçeği artırılarak veya içeriği farklı bir kapasiteye atayarak bu sorun çözülebilir.If this happens too frequently, the issue can be resolved by scaling up the Premium capacity or by assigning the content to a different capacity.
Kapasite Yöneticileri (ve Power BI hizmet yöneticileri) bunun ne zaman yaşandığını belirlemek için Sorgu Hataları ölçümünü izleyebilir.Capacity Admins (and Power BI service administrators) can monitor the Query Failures metric to determine when this happens. Sistemin aşırı yüklenmesi durumunda tüm işlemleri sıfırlayarak kapasiteyi yeniden başlatabilirler.They can also restart the capacity, resetting all operations in case of system overload.
Yenilemeler neden zamanında başlamıyor?Why are refreshes not starting on schedule?
Zamanlanan yenileme başlangıç süreleri garanti edilmez.Scheduled refresh start times are not guaranteed. Power BI hizmetinin her zaman arka plan işlemlerinden ziyade etkileşimli işlemleri önceliklendirdiğini unutmayın.Recall that the Power BI service will always prioritize interactive operations over background operations. Yenileme, iki koşul karşılandığında oluşabilen bir arka plan işlemidir:Refresh is a background operation that can occur when two conditions are met:
Yeterli bellek bulunduğundaThere is sufficient memory
Premium kapasite için desteklenen eşzamanlı yenileme sayısı aşılmadığındaThe number of supported concurrent refreshes for the Premium capacity is not exceeded
Koşullar karşılanmazsa, koşullar uygun hale gelene kadar yenileme kuyruğa alınır.When the conditions are not met, the refresh is queued until the conditions are favorable.
Tam yenileme için, mevcut veri kümesi bellek boyutunun en az iki katının gerektiğini unutmayın.For a full refresh, recall that at least double the current dataset memory size is required. Yeterli bellek yoksa çıkarma işlemi belleği boşaltana kadar yenileme başlayamaz. Bu da veri kümelerinin biri veya daha fazlası etkin olmayan ve çıkarılabilir duruma gelene kadar gecikme yaşanacak demektir.If sufficient memory is not available, then the refresh cannot commence until model eviction frees up memory - this means delays until one or more datasets becomes inactive and can be evicted.
Desteklenen en fazla eşzamanlı yenileme sayısının, arka uç sanal çekirdeklerinin 1.5 katının yukarı yuvarlanmış hali olarak ayarlandığını unutmayın.Recall that the supported number of maximum concurrent refreshes is set to 1.5 times the backend v-cores, rounded up.
Zamanlanmış yenileme, sonraki zamanlanmış yenileme başlamadan önce başlayamadığında başarısız olur.A scheduled refresh will fail when it cannot commence before the next scheduled refresh is due to commence. Kullanıcı arabiriminden el ile tetiklenen bir isteğe bağlı yenileme, başarısız olmadan önce en az üç kere çalışmayı dener.An on-demand refresh triggered manually from the UI will attempt to run up to three times before failing.
Kapasite Yöneticileri (ve Power BI hizmet yöneticileri), zamanlanan süre ve işlemin başlangıcı arasındaki ortalama gecikmeyi tespit etmek için Ortalama Yenileme Bekleme Süresi (dakika) ölçümünü izleyebilir.Capacity Admins (and Power BI service administrators) can monitor the Average Refresh Wait Time (minutes) metric to determine average lag between the scheduled time and the start of the operation.
Genellikle yönetime yönelik bir öncelik olmasa da, zamanında veri yenilemelerini etkilemek için yeterli bellek bulunduğundan emin olun.While not usually an administrative priority, to influence on-time data refreshes, ensure that sufficient memory is available. Bu, veri kümelerini bilinen yeterli kaynaklara sahip kapasiteler için ayrı tutmayı içerebilir.This may involve isolating datasets to capacities with known sufficient resources. Yöneticilerin, çarpışmaları en az indirmek amacıyla zamanlanan veri yenileme sürelerini kademelendirmek veya azaltmak için veri kümesi sahipleriyle çalışma olanağı da bulunur.It's also possible that admins could coordinate with dataset owners to help stagger or reduce scheduled data refresh times to minimize collisions. Bir yöneticinin yenileme kuyruğunu görüntülemesi veya veri kümesi zamanlamalarını alması mümkün değildir.Note that it's not possible for an administrator to view the refresh queue, or to retrieve dataset schedules.
Yenilemeler neden yavaş?Why are refreshes slow?
Yenilemeler yavaş olabilir veya yavaş gibi algılanabilir (önceki soruda ele alındığı gibi).Refreshes can be slow - or perceived to be slow (as the previous common question addresses).
Yenileme gerçekten yavaşsa, bu çeşitli nedenlerden kaynaklanabilir:When the refresh is in fact slow, it can be due to several reasons:
Yetersiz CPU (yenileme işlemi CPU’yu yoğun olarak kullanabilir).Insufficient CPU (refresh can be very CPU-intensive).
Yenileme duraklamasına neden olan yetersiz bellek (koşullar yeniden başlatma için uygun olduğunda yenilemenin baştan başlamasını gerektirir).Insufficient memory, resulting in refresh pausing (which requires the refresh to start over when conditions are favorable to recommence).
Veri kaynağı sisteminin yanıt hızı, ağ gecikme süresi, geçersiz izinler veya ağ geçidi aktarım hızının da dahil olduğu, kapasiteyle ilgili olmayan sebepler.Non-capacity reasons, including datasource system responsiveness, network latency, invalid permissions or gateway throughput.
Veri hacmi, aşağıda anlatıldığı gibi artımlı yenilemeyi yapılandırmak için iyi bir nedendir.Data volume - a good reason to configure incremental refresh, as discussed below.
Kapasite Yöneticileri (ve Power BI hizmet yöneticileri) zaman içinde karşılaştırma için bir kıyaslama gerçekleştirmek için Ortalama Yenileme Süresi (dakika) ölçümünü, zamanlanan süre ve işlemin başlangıcı arasındaki gecikmeyi belirlemek için de Ortalama Yenileme Bekleme Süresi (dakika) ölçümünü izleyebilir.Capacity Admins (and Power BI service administrators) can monitor the Average Refresh Duration (minutes) metric to determine a benchmark for comparison over time, and the Average Refresh Wait Time (minutes) metrics to determine average lag between average lag between the scheduled time and the start of the operation.
Artımlı yenileme, özellikle büyük model tabloları için veri yenileme süresini önemli ölçüde azaltabilir.Incremental refresh can significantly reduce data refresh duration, especially for large model tables. Artımlı yenilemenin sunduğu dört avantaj bulunur:There are four benefits associated with incremental refresh:
Yenilemeler daha hızlıdır - Tablonun sadece alt kümesinin yüklenmesi gerekir. Böylelikle CPU ve bellek kullanımı azalır ve birden fazla bölüm yenilenirken paralellik daha yüksek olabilir.Refreshes are faster - Only a subset of a table needs loading, reducing CPU and memory usage, and parallelism can be higher when refreshing multiple partitions.
Yenilemeler sadece gerekli olduğunda gerçekleşir - Artımlı yenileme ilkeleri sadece veriler değiştirildiğinde yüklenecek şekilde yapılandırılabilir.Refreshes occur only when required - Incremental refresh policies can be configured to load only when data has changed.
Yenilemeler daha güvenilirdir - Geçici veri kaynağıyla kurulan kısa çalışan bağlantılar kesintilere daha az duyarlıdır.Refreshes are more reliable - Shorter running connections to volatile datasource systems are less susceptible to disconnection.
Modeller kırpılmış olarak kalır - Artımlı yenileme ilkeleri, geçmişi otomatik olarak kayan zaman penceresinin ötesinde de kaldıracak şekilde yapılandırılabilir.Models remain trim - Incremental refresh policies can be configured to automatically remove history beyond a sliding window of time.
Daha fazla bilgi edinmek için bkz. Power BI Premium’da artımlı yenileme.To learn more, see Incremental refresh in Power BI Premium.
Veri yenilemeleri neden tamamlanmıyor?Why are data refreshes not completing?
Veri yenileme başlarsa ancak tamamlanamazsa bunun çeşitli sebepleri olabilir:When the data refresh commences but fails to complete, it can be due to several reasons:
Premium kapasitede yalnızca bir model olsa da yetersiz kalan bellek (örneğin model boyutu) çok büyükse.Insufficient memory, even if there is only one model in the Premium capacity, i.e. the model size is very large.
Veri kaynağı sistemi bağlantısının kopması, geçersiz izinler veya ağ geçidi hatası dahil olmak üzere kapasiteyle ilgili olmayan sebepler.Non-capacity reasons, including datasource system disconnection, invalid permissions or gateway error.
Kapasite Yöneticileri (ve Power BI hizmet yöneticileri) Belleğin yetersiz kalmasından ötürü Yenileme Hataları ölçümünü izleyebilir.Capacity Admins (and Power BI service administrators) can monitor the Refresh Failures due to out of Memory metric.
Modelleri iyileştirmeOptimizing models
Etkili ve ölçeklenebilir bir çözüm sunmak için model tasarımının en uygun halde olması önemlidir.Optimal model design is crucial to delivering an efficient and scalable solution. Ancak, bununla ilgili ayrıntılı bir tartışma sunma, bu makalenin kapsamını aşar.However, it's beyond the scope of this article to provide a complete discussion. Bunun yerine, modeller iyileştirilirken dikkate alınması gereken önemli hususlar bu bölümde sunulacaktır.Instead, this section will provide key areas for consideration when optimizing models.
Power BI barındırılan modelleri iyileştirmeOptimizing Power BI hosted models
Bir Premium kapasitede barındırılan modelleri iyileştirme işlemi veri kaynaklarında ve model katmanlarında gerçekleştirilebilir.Optimizing models hosted in a Premium capacity can be achieved at the datasource(s) and model layers.
İçeri aktarma modeline yönelik iyileştirme olanaklarını göz önünde bulundurun:Consider the optimization possibilities for an Import model:
Veri kaynağı katmanında:At the datasource layer:
İlişkisel veri kaynakları, verileri önceden tümleştirerek, uygun dizinler uygulanarak, artımlı yenileme dönemleriyle uyumlu olan tablo bölümleri tanımlayarak, hesaplamaları gerçekleştirerek (hesaplanan model tabloları ve sütunların yerine) veya görünümlere hesaplama mantığı ekleyerek mümkün olan en hızlı yenileme süresini sunmak için iyileştirilebilir.Relational data sources can be optimized to ensure the fastest possible refresh by pre-integrating data, applying appropriate indexes, defining table partitions that align to incremental refresh periods, and materializing calculations (in place of calculated model tables and columns) or adding calculation logic to views.
İlişkisel olmayan veri kaynakları ilişkisel depolarla önceden tümleştirilebilir.Non-relational data sources can be pre-integrated with relational stores.
Ağ geçitlerinin, tercihen ayrılmış makinelerde, yeterli ağ genişliğiyle, veri kaynaklarının yakınında yer alan yeterli kaynaklarının bulunduğundan emin olun.Ensure that gateways have enough resources, preferably on dedicated machines, with sufficient network bandwidth and in close proximity to the data sources.
Model katmanında:At the model layer:
Power Query sorgu tasarımları, karmaşık dönüşümleri (özellikle farklı veri kaynaklarını birleştirenleri) en aza indirebilir veya kaldırabilir (veri ambarları bunu Ayıklama-Dönüştürme-Yükleme aşamasında gerçekleştirir).Power Query query designs can minimize or remove complex transformations and especially those that merge different data sources (data warehouses achieve this during their Extract-Transform-Load stage). Uygun veri kaynağı gizlilik düzeylerinin ayarlandığından emin olarak, sorgularda birleşik bir sonuç üretmek için Power BI’ın tam sonuçları yüklemesini gerektirmeyebilir.Also, ensuring that appropriate datasource privacy levels are set, this can avoid requiring Power BI to load full results to produce a combined result across queries.
Model, yüklenecek veriyi belirler ve model boyutunun üzerinde doğrudan etkiye sahiptir.The model structure determines the data to load and has a direct impact on the model size. Sütunları, satırları kaldırarak (özellikle geçmiş verilerini) veya özetlenen verileri yükleyerek (ayrıntılı verileri yükleme pahasına) gereksiz verileri yüklemesi engellenecek şekilde tasarlanabilir.It can be designed to avoid loading unnecessary data by removing columns, removing rows (especially historic data) or by loading summarized data (at the expense of loading detailed data). Verimli şekilde depolama veya sıkıştırma yapamayan yüksek kardinaliteli sütunlar kaldırılarak (özellikle metin sütunları) boyut büyük ölçüde azaltılabilir.Dramatic size reduction can be achieved by removing high cardinality columns (especially text columns) which do not store or compress very efficiently.
Çift yönlü filtrelemeye izin vermeyi gerektiren bir sebep olmadıkça, tek yönlü ilişkiler yapılandırılarak sorgu performansı geliştirilebilir.Model query performance can be improved by configuring single direction relationships unless there is a compelling reason to allow bi-directional filtering. Çift yönlü filtrelemenin yerine CROSSFILTER işlevini kullanmayı da düşünebilirsiniz.Consider also using the CROSSFILTER function instead of bi-directional filtering.
Toplama tabloları, önceden özetlenmiş verileri yükleyerek hızlı sorgu yanıtları elde edebilir. Ancak, bunun sonucu olarak modelin boyutu büyür ve yenileme süreleri uzar.Aggregation tables can achieve fast query responses by loading pre-summarized data, however this will increase the size of the model and result in longer refresh times. Genellikle, toplama tabloları çok büyük modeller veya bileşik model tasarımları için ayrılmalıdır.Generally, aggregation tables should be reserved for very large models or Composite model designs.
Hesaplanan tablolar ve sütunlar model boyutunu artırıp yenileme süresinin uzamasına neden olur.Calculated tables and columns increase the model size and result in longer refresh times. Genellikle, veriler veri kaynağında gerçekleştirildiğinde veya hesaplandığında daha küçük bir depolama boyutu ve daha hızlı yenileme zamanı elde edilebilir.Generally, a smaller storage size and faster refresh time can be achieved when the data is materialized or calculated in the datasource. Bu mümkün değilse, Power Query özel sütunlar gelişmiş depolama sıkıştırması sunabilir.If this is not possible, using Power Query custom columns can offer improved storage compression.
Ölçümler ve RLS kuralları için DAX ifadelerini ayarlamaya yönelik bir fırsat olabilir. Pahalı formüllerden kaçınmak için mantık yeniden yazılabilirThere may be opportunity to tune DAX expressions for measures and RLS rules, perhaps rewriting logic to avoid expensive formulas
Artımlı yenileme, yenileme süresini önemli ölçüde azaltabilir ve bellek ve CPU tasarrufu sağlayabilir.Incremental refresh can dramatically reduce refresh time and conserve memory and CPU. Artımlı yenileme, model boyutlarının kırpmalarını saklayan geçmiş verilerini kaldıracak şekilde de yapılandırılabilir.The incremental refresh can also be configured to remove historic data keeping model sizes trim.
Farklı ve çakışan sorgu desenleri olduğunda, model iki model olarak yeniden tasarlanabilir.A model could be redesigned as two models when there are different and conflicting query patterns. Örneğin, bazı raporlar tüm geçmişte yüksek düzeyde toplama sunar ve 24 saatlik gecikme süresine izin verebilir.For example, some reports present high-level aggregates over all history, and can tolerate 24 hours' latency. Diğer raporlar bugünün verileriyle ilgilidir ve tek işlemlere ayrıntılı erişim gerektirir.Other reports are concerned with today's data and need granular access to individual transactions. Tüm raporları karşılamak için tek bir model tasarlamaktan ziyade her gereksinim için iyileştirilmiş iki model oluşturun.Rather than design a single model to satisfy all reports, create two models optimized for each requirement.
Bir DirectQuery modeli için iyileştirme olanaklarını göz önünde bulundurun.Consider the optimization possibilities for a DirectQuery model. Model, temel alınan veri kaynağına sorgu isteği gönderdikçe, yanıt veren model sorguları sunmak için veri kaynağının iyileştirilmesi büyük önem taşır.As the model issues query requests to the underlying datasource, datasource optimization is critical to delivering responsive model queries.
Veri kaynağı, verileri önceden tümleştirerek (model katmanında mümkün değildir), uygun dizinleri uygulayarak, tablo bölümlerini tanımlayarak, özetlenmiş verileri gerçekleştirerek (dizinlenmiş görünümlerle) ve hesaplama miktarını en aza indirerek mümkün olan en hızlı sorgulamayı sunması için iyileştirilebilir.The datasource can be optimized to ensure the fastest possible querying by pre-integrating data (which is not possible at the model layer), applying appropriate indexes, defining table partitions, materializing summarized data (with indexed views), and minimizing the amount of calculation. En iyi deneyim, doğrudan sorgular sadece filtreye ihtiyaç duyduğunda ve iç birleşimleri dizinlenmiş tablolar veya görünümler arasında gerçekleştirdiğinde elde edilir.The best experience is achieved when pass-through queries need only filter and perform inner joins between indexed tables or views.
Ağ geçitlerinin, tercihen ayrılmış makinelerde, yeterli ağ genişliğiyle, veri kaynaklarının yakınında yer alan yeterli kaynaklarının bulunduğundan emin olun.Ensure that gateways have enough resources, preferably on dedicated machines, with sufficient network bandwidth and in close proximity to the datasource.
Power Query sorgu tasarımları tercihen dönüşüm uygulamamalıdır. Aksi takdirde, dönüşümleri en az düzeyde tutmaya çalışın.Power Query query designs should preferably apply no transformations - otherwise attempt to keep transformations to an absolute minimum.
Çift yönlü filtrelemeye izin vermeyi gerektiren bir sebep olmadıkça, tek yönlü ilişkiler yapılandırılarak sorgu performansı geliştirilebilir.Model query performance can be improved by configuring single direction relationships unless there is a compelling reason to allow bi-directional filtering. Ayrıca, bilgi tutarlılığının zorlandığını varsaymak için model ilişkileri (durum bu olduğunda) yapılandırılmalıdır. Sonuç olarak, daha verimli iç birleşimler (dış birleşimlerin yerine) kullanan veri kaynağı sorguları ortaya çıkar.Also, model relationships should be configured to assume referential integrity is enforced (when this is the case) and will result in datasource queries using more efficient inner joins (instead of outer joins).
Mümkün olduğunda, Power Query sorgusu özel sütunları veya model hesaplanmış sütunları oluşturmaktan kaçının.Avoid creating Power Query query custom columns or model calculated column - materialize these in the datasource, when possible.
Ölçümler ve RLS kuralları için DAX ifadelerini ayarlamaya yönelik bir fırsat olabilir. Pahalı formüllerden kaçınmak için mantık yeniden yazılabilir.There may be opportunity to tune DAX expressions for measures and RLS rules, perhaps rewriting logic to avoid expensive formulas.
Birleşik bir model için iyileştirme olanaklarını göz önünde bulundurun.Consider the optimization possibilities for a Composite model. Birleşik modelin içeri aktarma ve DirectQuery tablolarının karışımına olanak tanıdığını unutmayın.Recall that a Composite model enables a mix of import and DirectQuery tables.
Genellikle, İçeri aktarma ve DirectQuery modellerine yönelik iyileştirmeler, bu depolama modlarını kullanan Birleşik model tabloları için geçerlidir.Generally, the optimization for Import and DirectQuery models apply to Composite model tables that use these storage modes.
Boyut türü tabloları (iş varlıklarını temsil eder) ikili depolama modu ve olgu türü tablolar (sıklıkla büyük tablolar olur ve işletimsel olguları temsil eder) olarak yapılandırarak dengeli bir tasarım elde etmeye çalışın.Typically, strive to achieve a balanced design by configuring dimension-type tables (representing business entities) as Dual storage mode and fact-type tables (often large tables, representing operational facts) as DirectQuery storage mode. İkili tasarım modu, hem İçeri aktarma hem de DirectQuery depolama modunun kullanıldığı anlamına gelir. Bu, Power BI hizmetinin doğrudan sorgu için yerel bir sorgu oluştururken kullanılacak en verimli depolama modunu kararlaştırmasına olanak tanır.Dual storage mode means both Import and DirectQuery storage modes, and this allows the Power BI service to determine the most efficient storage mode to use when generating a native query for pass-through.
Ağ geçitlerinin, tercihen ayrılmış makinelerde, yeterli ağ genişliğiyle, veri kaynaklarının yakınında yer alan yeterli kaynaklarının bulunduğundan emin olunEnsure that gateways have enough resources, preferably on dedicated machines, with sufficient network bandwidth and in close proximity to the data sources
İçeri aktarma depolama modu olarak yapılandırılan toplama tabloları, DirectQuery sorgu modunda olgu türü tabloları özetlemek için kullanıldığında önemli sorgu performansı artışı sunabilir.Aggregations tables configured as Import storage mode can deliver dramatic query performance enhancements when used to summarize DirectQuery storage mode fact-type tables. Bu durumda, toplama tabloları modelin boyutunu ve yenileme süresini artırır. Bu, genelde daha hızlı sorgular için kabul edilebilir bir ödünleşmedir.In this case, aggregation tables will increase the size of the model and increase refresh time, and often this is an acceptable tradeoff for faster queries.
Dışarıda barındırılan modelleri iyileştirmeOptimizing externally hosted models
Power BI’da barındırılan modelleri iyileştirme bölümünde tartışılan birçok iyileştirme olanağı, Azure Analysis Services ve SQL Server Analysis Services ile geliştirilen modeller için de geçerlidir.Many optimization possibilities discussed in the Optimizing Power BI hosted models section apply also to models developed with Azure Analysis Services and SQL Server Analysis Services. Bileşik modeller ve toplama tabloları gibi şu anda desteklenmeyen özellikler açık özel durumlardandır.Clear exceptions are certain features which are not currently supported, including Composite models and aggregation tables.
Dışarıda barındırılan veri kümelerine yönelik bir diğer durum da, Power BI hizmetiyle ilişkili olarak veritabanı barındırmadır.An additional consideration for externally-hosted datasets is the database hosting in relation to the Power BI service. Azure Analysis Services için bu, Azure kaynağını Power BI kiracısıyla aynı bölgede (ana bölge) oluşturma anlamına gelir.For Azure Analysis Services, this means creating the Azure resource in the same region as the Power BI tenant (home region). Bu, SQL Server Analysis Services ve IaaS için de VM’i aynı bölgede barındırma, şirket içi için de verimli bir ağ geçidi kurulumu sağlama anlamına gelir.For SQL Server Analysis Services, for IaaS, this means hosting the VM in the same region, and for on-premises, it means ensuring an efficient gateway setup.
Bunun yanı sıra, Azure Analysis Services veritabanlarının ve SQL Server Analysis Services tablosal veritabanlarının modellerin belleğe tam olarak yüklenmesini gerektirdiğini ve sorgulamayı desteklemek için sürekli olarak orada kaldıklarını hatırlamak faydalı olabilir.As an aside, it may be of interest to note that Azure Analysis Services databases and SQL Server Analysis Services tabular databases require that their models be loaded fully into memory and that they remain there at all times to support querying. Power BI hizmeti gibi, modelin yenileme esnasında çevrimiçi kalması gerekiyorsa yeterli belleğin bulunması gerekir.Like the Power BI service, there needs to be sufficient memory for refreshing if the model must remain online during the refresh. Power BI hizmetinin aksine, kullanıma göre modellerin bellekte eski veya yeni hale getirilmesine yönelik bir kavram bulunmamaktadır.Unlike the Power BI service, there is no concept that models are automatically aged in and out of memory according to usage. Bu nedenle, daha düşük bellek kullanımı ile model sorgulamayı en üst düzeye çıkarmak için Power BI Premium daha verimli bir yaklaşım sunar.Power BI Premium, therefore, offers a more efficient approach to maximize model querying with lower memory usage.
Kapasite planlamasıCapacity planning
Premium kapasitesinin boyutu kullanılabilir olan bellek ve işlemci kaynaklarını ve kapasiteye uygulanan limitleri belirler.The size of a Premium capacity determines its available memory and processor resources and limits imposed on the capacity. Premium kapasitelerinin sayısı da dikkate alınır. Birden fazla Premium kapasitesinin oluşturulması iş yüklerini birbirinden yalıtmaya yardımcı olabilir.The number of Premium capacities is also a consideration, as creating multiple Premium capacities can help isolate workloads from each other. Depolamanın kapasite düğümü başına 100 TB olduğunu ve bu durumun herhangi bir iş yükü için yeterli olduğunu unutmayın.Note that storage is 100 TB per capacity node, and this is likely to be more than sufficient for any workload.
Premium kapasitelerinin sayısını ve boyutunu belirleme, özellikle oluşturduğunuz ilk kapasiteler için zorlayıcı bir durum olabilir.Determining the size and number of Premium capacities can be challenging, especially for the initial capacities you create. Kapasiteyi boyutlandırmanın ilk adımı, beklenen günlük kullanımı temsil eden ortalama iş yükünü anlamadır.The first step when capacity sizing is to understand the average workload representing expected day-to-day usage. Tüm iş yüklerinin eşit olmadığını anlamak önemlidir.It's important to understand that not all workloads are equal. Örneğin, ölçeğin bir ucunda tek bir görsel içeren bir rapor sayfasına 100 kullanıcının erişmesini sağlama hedefine kolayca erişilebilir.For example - at one end of a spectrum - 100 concurrent users accessing a single report page that contains a single visual is easily achievable. Ancak, ölçeğin diğer ucunda, her biri rapor sayfasında 100 görsel içeren 100 farklı rapora aynı anda 100 kullanıcının erişmesini sağlama, kapasite kaynaklarından oldukça farklı taleplerde bulunacaktır.Yet - at the other end of the spectrum - 100 concurrent users accessing 100 different reports, each with 100 visuals on the report page, is going to make very different demands of capacity resources.
Bu nedenle, Kapasite Yöneticilerinin ortamınıza, içeriklerinize ve beklenen kullanımlara özgü birçok farklı etkeni göz önünde bulundurması gerekir.Capacity Admins will therefore need to consider many factors specific to your environment, content and expected usage. Burada üstün gelen hedef, tutarlı sorgu süreleri, kabul edilebilir bekleme süreleri ve çıkarma oranları sunarken kapasite kullanımını en üst düzeye çıkarmadır.The overriding objective is to maximize capacity utilization while delivering consistent query times, acceptable wait times, and eviction rates. Göz önünde bulundurulacak etkenler şunları içerebilir:Factors for consideration can include:
Model boyutu ve veri özellikleri - Sorgulama veya yenilemeye izin vermek için içeri aktarma modelleri belleğe tamamen yüklenmelidir.Model size and data characteristics - Import models must be fully loaded into memory to allow querying or refreshing. LC/DQ veri kümeleri, karmaşık ölçümleri veya RLS kurallarını değerlendirmek için önemli işlemci süresi ve muhtemelen önemli ölçüde bellek gerektirebilir.LC/DQ datasets can require significant processor time and possibly significant memory to evaluate complex measures or RLS rules. Bellek ve işlemci boyutu ve LC/DQ sorgu aktarım hızı kapasite boyutuyla kısıtlıdır.Memory and processor size, and LC/DQ query throughput are constrained by the capacity size.
Eşzamanlı etkin modeller - Farklı içeri aktarma modellerinin eşzamanlı olarak sorgulanması, modeller bellekte durdukça en iyi yanıtlama hızını ve performansı sunar.Concurrent active models - The concurrent querying of different import models will deliver best responsiveness and performance when they remain in memory. Yoğun şekilde sorgulanan modelleri barındırmak için yeterli bellek olmalıdır. Bunların yenilenmesi için de ek bellek gerekir.There should be sufficient memory to host all heavily-queried models, with additional memory to allow for their refresh.
İçeri aktarma modelini yenileme - Yenileme türü (tam veya artımlı), Power Query sorgularının süresi ve karmaşıklığı ve hesaplanan tablo/sütun mantığının bellek ve özellikle de işlemci kullanımı üzerinde etkisi olabilir.Import model refresh - The refresh type (full or incremental), duration and complexity of Power Query queries and calculated table/column logic can impact on memory and especially processor usage. Eş zamanlı yenilemeler kapasite boyutuyla kısıtlanır (1,5 x arka uç sanal çekirdek sayısı, yukarıya doğru yuvarlanır).Concurrent refreshes are constrained by the capacity size (1.5 x backend v-cores, rounded up).
Eşzamanlı sorgular - İşlemci veya LC/DQ bağlantıları kapasite sınırını aştığında çoğu eşzamanlı sorgu yanıt vermeyen raporlara neden olabilir.Concurrent queries - Many concurrent queries can result in unresponsive reports when processor or LC/DQ connections exceeds the capacity limit. Bu durum özellikle de çok sayıda görsel içeren rapor sayfaları için geçerlidir.This is especially the case for report pages that include many visuals.
Veri akışları ve sayfalandırılmış raporlar - Kapasite, veri akışlarını ve sayfalandırılmış raporları destekleyecek şekilde yapılandırılabilir. Her biri, kapasite belleğinin yapılandırılabilir en fazla yüzdesini gerektirir.Dataflows and paginated reports - The capacity can be configured to support dataflows and paginated reports, with each requiring a configurable maximum percentage of capacity memory. Bellek, dinamik olarak veri akışlarına ayrılsa da istatistiksel olarak sayfalandırılmış raporlara ayrılır.Memory is dynamically allocated to dataflows, but is statically allocated to paginated reports.
Bu faktörlere ek olarak, Kapasite Yöneticileri birden fazla kapasite oluşturmayı düşünebilir.In addition to these factors, Capacity Admins can consider creating multiple capacities. Birden fazla kapasite, iş yüklerinin yalıtılmasına olanak tanır ve öncelikli iş yüklerinin garanti kaynaklara sahip olmasını sağlayacak şekilde yapılandırılabilir.Multiple capacities allow for the isolation of workloads and can be configured to ensure priority workloads have guaranteed resources. Örneğin, iş açısından kritik iş yüklerini self servis BI (SSBI) iş yüklerinden ayırmak için iki kapasite oluşturulabilir.For example, two capacities can be created to separate business-critical workloads from self-service BI (SSBI) workloads. İş açısından kritik kapasite, sadece BT departmanına sağlanan yazar erişimi ile garanti kaynaklar sunarak büyük kurumsal modelleri ayrı tutmak için kullanılabilir.The business-critical capacity can be used to isolate large corporate models providing them with guaranteed resources, with authoring access granted only to the IT department. İş analistlerine sağlanan erişim ile, SSBI kapasitesi sayısı gittikçe artan küçük modelleri barındırmak için kullanılabilir.The SSBI capacity can be used to host a growing number of smaller models, with access granted to business analysts. SSBI kapasitesi, zaman zaman kabul edilebilir sorgu veya yenileme beklemeleri yaşayabilir.The SSBI capacity may at times experience query or refresh waits that are tolerable.
Zamanla, Kapasite Yöneticileri içerikleri çalışma alanlarının arasında taşıyarak, çalışma alanlarını kapasitelerin arasında taşıyarak veya kapasitelerin ölçeğini artırıp azaltarak çalışma alanlarını dengeleyebilir.Over time, Capacity Admins can balance workspaces across capacities by moving content between workspaces, or workspaces between capacities, and by scaling capacities up or down. Genellikle, daha büyük modelleri barındırmak için ölçeği artırıp daha fazla eşzamanlılık için ölçeği genişletirsiniz.Generally, to host larger models you scale-up and for higher concurrency you scale out.
Lisans satın almanın sanal çekirdekleri bulunan kiracıyı sağladığını unutmayın.Recall that purchasing a license provides the tenant with v-cores. P3 aboneliği satın alınarak bir veya dört taneye kadar Premium kapasite oluşturulabilir. Örn. 1 x P3, veya 2 x P2, veya 4 x P1.The purchase of a P3 subscription can be used to create one, or up to four Premium capacities, i.e. 1 x P3, or 2 x P2, or 4 x P1. Boyutu P2 kapasitesinden P3 kapasitesine artırmadan önce iki tane P1 kapasitesi oluşturmak için sanal çekirdeklerin bölünmesi düşünülebilir.Also, before upsizing a P2 capacity to a P3 capacity, consideration can be given to splitting the v-cores to create two P1 capacities.
Yaklaşımları test etmeTesting approaches
Kapasite boyutu kararlaştırıldığında, denetimli bir ortam oluşturularak test gerçekleştirilebilir.Once a capacity size is decided, testing can be performed by creating a controlled environment. Bir Azure (A SKU’lar) kapasitesi oluşturma, pratik ve ekonomik seçeneklerden biridir. P1 kapasitesinin boyutu A4 kapasitesinin, P2 ve P3 kapasitelerinin boyutları da sırasıyla A5 ve A6 kapasitelerinin boyutlarıyla aynıdır.A practical and economic option is to create an Azure (A SKUs) capacity, noting that a P1 capacity is the same size as an A4 capacity, with the P2 and P3 capacities the same size as the A5 and A6 capacities, respectively. Hızla oluşturulabilen Azure kapasiteleri saatlik olarak faturalandırılır.Azure capacities can be created quickly and are billed on an hourly basis. Böylelikle, tahakkuk eden maliyetleri durdurmak için test etme tamamlandıktan sonra kolayca silinebilirler.So, once testing is complete, they can be easily deleted to stop accruing costs.
Test içeriği Azure kapasitesinde oluşturulan çalışma alanlarına eklenebilir. Ardından, tek bir kullanıcı olarak gerçekçi ve temsili bir sorgu iş yükü oluşturmak için raporlar çalıştırılabilir.The test content can be added to the workspaces created on the Azure capacity, and then as a single user can run reports to generate a realistic and representative workload of queries. İçeri aktarma modelleri varsa, her model için bir yenileme de gerçekleştirilmelidir.If there are import models, a refresh for each model should be performed also. Kaynak kullanımını anlamak için tüm ölçümleri gözden geçirmek amacıyla izleme araçları kullanılabilir.Monitoring tools can then be used to review all metrics to understand resource utilization.
Testlerin tekrarlanabilir olması önemlidir.It's important that the tests are repeatable. Testler birkaç kez çalıştırılmalı ve her seferinde yaklaşık olarak aynı sonucu sunmalıdır.Tests should be run several times and they should deliver approximately the same result each time. Gerçek üretim koşulları altında iş yükünü tahmin etmek için bu sonuçların ortalaması kullanılabilir.An average of these results can be used to extrapolate and estimate a workload under true production conditions.
Zaten bir kapasiteniz ve testi yüklemek istediğiniz raporlarınız varsa, hızla bir yük testi oluşturmak için PowerShell yük oluşturma aracını kullanın.If you already have a capacity and the reports you want to load test for, use the PowerShell load generating tool to quickly generate a load test. Araç, her raporun bir saat içinde kapasitenizin kaç tane örneğini çalıştırabileceğini tahmin etmenize olanak tanır.The tool enables you to estimate how many instances of each report your capacity can run in an hour. Kapasitenizin ayrı rapor işleme veya farklı raporları paralel olarak işleme yeteneğini değerlendirmek için aracı kullanabilirsiniz.You can use the tool to evaluate your capacity's ability for individual report rendering or for rendering several different reports in parallel. Daha fazla bilgi için şu videoyu izleyin: Microsoft Power BI: Premium kapasite.For more information, see the video Microsoft Power BI: Premium capacity.
Daha karmaşık bir test oluşturmak için, gerçekçi bir iş yüküne benzetim yapan bir yük test etme uygulaması geliştirmeyi düşünebilirsiniz.To generate a more complex test, consider developing a load testing application that simulates a realistic workload. Daha fazla bilgi için bkz. Visual Studio Yük Testi ile Power BI Uygulamalarında Yük Test Etme.For more information, see the webinar Load Testing Power BI Applications with Visual Studio Load Test.
Bu makale, Veri Platformu MVP’si ve Bitwise Solutions’da bağımsız BI uzmanı olan Peter Myers tarafından yazılmıştır.This article was written by Peter Myers, Data Platform MVP and independent BI expert with Bitwise Solutions.
Premium kapasite senaryolarıPremium capacity scenarios