Alıştırma - Uygulama performansını iyileştirme - Training

10 dakika

Bu alıştırmada yeni bir performans senaryosu gözlemleyip uygulamayı ve sorguları iyileştirerek sorunu çözeceksiniz.

Azure SQL ile uygulama performansını iyileştirme

Bazı durumlarda mevcut uygulamayı ve SQL sorgusu iş yükünü Azure'a geçirmek, sorguları iyileştirmeye ve ayarlamaya yönelik fırsatlar doğurabilir.

Müşterilerin derecelendirmelerini içeren derecelendirme sistemi sağlamak üzere AdventureWorks siparişlerine yönelik web sitesinde yeni bir uzantıyı desteklemek amacıyla, çok yoğun bir dizi eşzamanlı INSERT etkinliği için yeni bir tablo eklemeniz gerekir. SQL sorgu iş yükünü veritabanı ve işlem günlüğü için yerel ssd sürücüsü olan SQL Server 2022'ye sahip bir geliştirme bilgisayarında test ettiniz.

Genel amaçlı katmanını (8 sanal çekirdekli) kullanarak testinizi Azure SQL Veritabanı’na taşıdığınızda INSERT iş yükü yavaşlıyor. Yeni iş yükünü desteklemek için hizmet hedefini veya katmanı değiştirmeniz mi yoksa uygulamaya bakmanız mı gerekiyor?

Bu alıştırmanın tüm betiklerini kopyaladığınız GitHub deposundaki 04-Performance\tuning_applications klasöründe veya indirdiğiniz zip dosyasında bulabilirsiniz.

Uygulama için yeni tablo oluşturma

Nesne Gezgini’nde AdventureWorks veritabanını seçin. Veritabanında tablo oluşturmak üzere order_rating_ddl.sql betiğini açmak için Dosya>Aç>Dosyasını kullanın.AdventureWorks Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:

DROP TABLE IF EXISTS SalesLT.OrderRating;
GO
CREATE TABLE SalesLT.OrderRating
(OrderRatingID int identity not null,
SalesOrderID int not null,
OrderRatingDT datetime not null,
OrderRating int not null,
OrderRatingComments char(500) not null);
GO

Betiği çalıştırmak için Yürüt'e tıklayın.

Sorgu yürütmeyi izlemek için sorguları yükleme

Şimdi etkin sorgular, bekleme süreleri ve G/Ç ile ilgili sorgu performansını gözlemlemek üzere dinamik yönetim görünümleri (DMV) için bazı T-SQL sorguları yükleyelim. Bu sorguların tümünü AdventureWorks veritabanı bağlamında yükleyin.

Nesne Gezgini’nde AdventureWorks veritabanını seçin. Etkin>SQL sorgularına bakmak için dosya açma>dosyasını kullanarak sqlrequests.sql betiğini açın. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:

SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;

Nesne Gezgini’nde AdventureWorks veritabanını seçin. Sayıya göre en iyi bekleme türlerine bakmak üzere top_waits.sql betiğini açmak için Dosya>Aç>Dosyasını kullanın. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:
```
SELECT * FROM sys.dm_os_wait_stats
ORDER BY waiting_tasks_count DESC;
```
Nesne Gezgini’nde AdventureWorks veritabanını seçin. İşlem günlüğü yazma işlemlerinin gecikme süresini gözlemlemek üzere tlog_io.sql betiğini açmak için Dosya>Aç>Dosyasını kullanın. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:
```
SELECT io_stall_write_ms/num_of_writes as avg_tlog_io_write_ms, * 
FROM sys.dm_io_virtual_file_stats
(db_id('AdventureWorks'), 2);
```

İş yükü betiğini yürütme için hazırlama

order_rating_insert_single.cmd iş yükü betiğini açın ve düzenleyin.

İlk alıştırmada size verilen yerine unique_id sunucu adını yazın -S parameter.
için ilk alıştırmada veritabanı dağıtımında sağladığınız parolayı değiştirin -P parameter.
Dosyadaki değişiklikleri kaydedin.

İş yükünü çalıştırma

PowerShell komut isteminde, bu modül etkinliği için dizini değiştirin:
```
cd c:<base directory>\04-Performance\tuning_applications
```
Aşağıdaki komutla iş yükünü çalıştırın:
```
.\order_rating_insert_single.cmd
```
Bu betik aşağıdaki T-SQL deyimini (order_rating_insert_single.sql betiğinde) çalıştırarak, 25 eşzamanlı kullanıcı çalıştırmak için ostress.exe programını kullanır:
```
DECLARE @x int;
SET @x = 0;
WHILE (@x < 500)
BEGIN
SET @x = @x + 1;
INSERT INTO SalesLT.OrderRating
(SalesOrderID, OrderRatingDT, OrderRating, OrderRatingComments)
VALUES (@x, getdate(), 5, 'This was a great order');
END
```
Bu betikten, bunun web sitesinden gelen verilerin gerçek bir gösterimi olmadığını görebilirsiniz. Ancak bu, birçok sıralama derecelendirmesinin veritabanına alınmasının benzetimini yapar.

DMV'leri ve iş yükü performansını gözlemleme

Şimdi performansı gözlemlemek için daha önce yüklediğiniz sorguları SQL Server Management Studio’da (SSMS) çalıştırın. sqlrequests.sql, top_waits.sql ve tlog_io.sql için sorguları çalıştırın.

Bu sorguları kullanarak aşağıdaki olguları gözlemleyebilirsiniz:

Birçok isteğin sürekli olarak değeri 0 olan bir > WRITELOG değeri vardırwait_type.
WRITELOG Bekleme türü, bekleme türleri için en yüksek sayılardan biridir.
İşlem günlüğüne (avg_tlog_io_write_mstlog_io.sql sonuç kümesindeki sütun) ortalama yazma süresi yaklaşık 2 ms'dir.

SSD sürücüsü olan bir SQL Server 2022 örneğinde bu iş yükünün süresi yaklaşık 10-12 saniyedir. Gen5 v8 çekirdeği olan Azure SQL Veritabanı’nda toplam süre yaklaşık 25 saniyedir.

WRITELOG Daha uzun bekleme sürelerine sahip bekleme türleri, işlem günlüğünde gecikmenin boşaltıldığını gösterir. Yazma işlemi başına 2 ms bekleme süresi pek fazla sayılmaz, ancak yerel bir SSD sürücüsünde bu bekleme süreleri 1 ms’nin altına düşebilir.

Bir çözüme karar verme

Sorun günlük yazma etkinliği oranının yüksek olması değildir. Azure portalında sys.dm_db_resource_stats yüzde 20-25'in üzerinde bir sayı gösterilmez (bunları sorgulamanız gerekmez). Sorun bir IOPS sınırı da değildir. Sorun, bu uygulama iş yükünün işlem günlüğüne yazma işlemlerinde düşük gecikme süresine duyarlı olması ve genel amaçlı katmanın bu tür gecikme gereksinimlerine yönelik tasarlanmamış olmasıdır. Azure SQL Veritabanı için beklenen G/Ç gecikme süresi 5-7 ms'dir.

Dekont

Genel Amaçlı Azure SQL Veritabanı belgelerinde yaklaşık G/Ç gecikme ortalamaları 5-7 (yazma işlemleri) ve 5-10 (okuma işlemleri) olarak belirtilir. Daha çok bu rakamlara yakın gecikmelerle karşılaşabilirsiniz. Genel amaçlı Azure SQL Yönetilen Örneği için gecikme süreleri benzerdir. Uygulamanız, G/Ç gecikme sürelerine çok duyarlıysa İş Açısından Kritik katmanları göz önünde bulundurun.

order_rating_insert_single.sql iş yükü T-SQL betiğini inceleyin. Her INSERT biri, işlem günlüğü temizleme gerektiren tek bir işlem işlemesidir.

Her ekleme için bir commit işlemi olması verimli değildir, ancak her commit çok hızlı olduğundan, yerel SSD sürücüsündeki uygulama bundan etkilenmemiştir. İş Açısından Kritik fiyatlandırma katmanı (hizmet hedefi veya SKU), daha düşük bir gecikme süresine sahip yerel SSD sürücüler sağlar. Bir uygulama iyileştirmesi olması mümkündür, bu nedenle iş yükü işlem günlüğü için G/Ç gecikme süresine duyarlı değildir.

İş yükünün T-SQL toplu işlemini yinelemeleri sarmalama BEGIN TRAN/COMMIT TRANINSERT amacıyla değiştirebilirsiniz.

Değiştirilmiş, daha verimli bir iş yükü çalıştırma

Daha verimli bir G/Ç performansı elde etmek için betiklerde düzenlemeler yapın ve bunları çalıştırın. Değiştirilen iş yükünü order_rating_insert.sql betiğinde bulabilirsiniz.

doğru sunucu adınızı ve parolanızı kullanmak için order_rating_insert.cmd dosyasını düzenleyerek iş yükü betiğini hazırlayın.
Önceki iş yükü betiğini çalıştırdığınıza benzer şekilde order_rating_insert.cmd betiğini kullanarak değiştirilen iş yükünü çalıştırın.

Yeni sonuçları gözlemleme

SSMS'de sqlrequests.sql için T-SQL betiğinin sonuçlarına bakın. Çok daha az WRITELOG beklemesi ve bu beklemeler için genel olarak daha az bekleme süresi olduğuna dikkat edin.

Artık iş yükü önceki yürütmeye göre çok daha hızlı çalışır. Bu, Azure’ın içinde veya dışında çalıştırılacak SQL sorguları için uygulamayı ayarlama örneğidir.

Dekont

Bu iş yükü, Yeniden Yönlendirme bağlantı türüne sahip bir Azure SQL Veritabanı örneğinde daha hızlı çalışabilir. Bu alıştırmada yaptığınız dağıtım, Azure dışından bağlandığınız için ara sunucu türü olan varsayılan bağlantı türünü kullanır. Yeniden Yönlendirme bağlantı türünün kullanılması, istemciden sunucuya gerekli gidiş dönüşler düşünüldüğünde iş yükünün hızını önemli ölçüde artırabilir.
İş yükü süresini gözlemleyin. İş yükü o kadar hızlı çalışır ki, daha önce bu etkinlikte kullanılan sorgulardan gelen tanılama verilerini gözlemlemek zor olabilir.

"İşlem grubu oluşturma" kavramı, Azure SQL’e bağlı olanlar da dahil olmak üzere çoğu uygulamaya yardımcı olabilir.

Bahşiş

Azure'da kaynak idaresi çok büyük işlemleri etkileyebilir ve belirtiler olacaktır LOG_RATE_GOVERNOR. Bu örnekte char(500) not null sütunu boşlukları doldurur ve büyük işlem günlüğü kayıtlarına neden olur. Bu sütunu değişken uzunluklu sütuna dönüştürerek performansı daha da iyileştirilebilirsiniz.

Sonraki ünitede Azure SQL'de akıllı performans hakkında bilgi edineceksiniz.

Devam et

Alıştırma - Uygulama performansını iyileştirme