Cvičení – optimalizace výkonu aplikace

10 min

V tomto cvičení se podíváte na nový scénář výkonu a vyřešíte ho optimalizací aplikace a dotazů.

Cvičení – optimalizace výkonu aplikace s Azure SQL

V některých případech může migrace stávající aplikace a úlohy dotazů SQL do Azure odhalit příležitosti pro optimalizaci a vyladění dotazů.

Kvůli podpoře nového rozšíření webu pro objednávky AdventureWorks, které má poskytnout systém hodnocení od zákazníků, potřebujete přidat novou tabulku pro masivní sadu souběžných aktivit typu INSERT. Otestovali jste úlohu dotazů SQL na vývojovém počítači s SQL Serverem 2022, který má místní jednotku SSD pro databázi a transakční protokol.

Když test přesunete do Azure SQL Database s použitím úrovně Pro obecné účely (8 virtuálních jader), je úloha INSERT pomalejší. Měli byste kvůli podpoře nové úlohy změnit cíl nebo úroveň služby nebo prověřit aplikaci?

Všechny skripty pro toto cvičení najdete ve složce 04-Performance\tuning_applications v úložišti GitHub, které jste naklonovali, nebo v souboru ZIP, který jste stáhli.

Vytvoření nové tabulky pro aplikaci

V Průzkumníku objektů vyberte databázi AdventureWorks. Pomocí souboru Otevřít>soubor otevřete skript order_rating_ddl.sql k vytvoření tabulky v AdventureWorks databázi.> V okně editoru dotazů by se měl zobrazit text podobný následujícímu:

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

Vyberte Spustit a spusťte skript.

Načtení dotazů pro monitorování provádění dotazů

Teď pojďme načíst některé dotazy T-SQL pro zobrazení dynamické správy, které sledují výkon dotazů – aktivní dotazy, čekání a V/V. Všechny tyto dotazy načtěte v kontextu databáze AdventureWorks.

V Průzkumníku objektů vyberte databázi AdventureWorks. Pomocí souboru Otevřít>soubor otevřete skript sqlrequests.sql a prohlédněte si aktivní dotazy SQL.> V okně editoru dotazů by se měl zobrazit text podobný následujícímu:

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;

V Průzkumníku objektů vyberte databázi AdventureWorks. Pomocí souboru Otevřít>soubor otevřete skript top_waits.sql a prohlédněte si hlavní typy čekání podle počtu.> V okně editoru dotazů by se měl zobrazit text podobný následujícímu:
```
SELECT * FROM sys.dm_os_wait_stats
ORDER BY waiting_tasks_count DESC;
```
V Průzkumníku objektů vyberte databázi AdventureWorks. Pomocí souboru Otevřít>soubor otevřete skript tlog_io.sql a sledujte latenci zápisů transakčního protokolu.> V okně editoru dotazů by se měl zobrazit text podobný následujícímu:
```
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);
```

Příprava skriptu úlohy ke spuštění

Otevřete a upravte skript úlohy order_rating_insert_single.cmd .

Nahraďte své unique_id jméno v prvním cvičení názvem serveru .-S parameter
Nahraďte heslo, které jste zadali v nasazení databáze z prvního cvičení .-P parameter
Uložte změny souboru.

Spuštění úlohy

V příkazovém řádku PowerShellu přejděte do adresáře pro aktivity tohoto modulu:
```
cd c:<base directory>\04-Performance\tuning_applications
```
Ke spuštění úlohy použijte následující příkaz:
```
.\order_rating_insert_single.cmd
```
Tento skript používá program ostress.exe k souběžnému provádění následujícího příkazu jazyka T-SQL 25 uživateli (ve skriptu order_rating_insert_single.sql):
```
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
```
Z tohoto skriptu můžete vidět, že se nejedná zrovna o skutečné znázornění data pocházejících z webu. Simuluje ale řadu hodnocení objednávek ingestovaných do databáze.

Sledování zobrazení dynamické správy a výkonu úlohy

Pro sledování výkonu teď v nástroji SQL Server Management Studio (SSMS) spustíte dotazy, které jste dříve načetli. Spusťte dotazy sqlrequests.sql, top_waits.sql a tlog_io.sql.

Pomocí těchto dotazů zjistíte následující fakta:

Mnoho požadavků má neustále wait_type hodnotu WRITELOG s hodnotou > 0.
Typ WRITELOG čekání je jedním z nejvyšších počtů pro typy čekání.
Průměrná doba zápisu do transakčního protokolu ( avg_tlog_io_write_ms sloupec v sadě výsledků tlog_io.sql ) je někde kolem 2 ms.

Doba trvání této úlohy v instanci SQL Serveru 2022 s jednotkou SSD je přibližně 10 až 12 sekund. Celková doba trvání u Azure SQL Database používající Gen5 V8 Core je přibližně 25 sekund.

WRITELOG Typy čekání s vyšší dobou čekání značí vyprázdnění latence do transakčního protokolu. Doba čekání 2 ms na zápis nevypadá jako dlouhá, ale u místní jednotky SSD můžou být tato čekání menší než 1 ms.

Rozhodnutí o řešení

Problémem není vysoké procento aktivity zápisů do protokolu. Na webu Azure Portal se sys.dm_db_resource_stats nezobrazují žádná čísla vyšší než 20–25 procent (nemusíte je dotazovat). Problémem není ani omezení IOPS. Problémem je to, že tato úloha aplikace je citlivá na nízkou latenci zápisů do transakčního protokolu a úroveň Pro obecné účely není určená pro tento typ požadavků na latenci. Očekávaná latence vstupně-výstupních operací pro Azure SQL Database je 5 až 7 ms.

Poznámka:

V dokumentaci Azure SQL Database s úrovní Pro obecné účely se průměrná latence V/V uvádí přibližně 5–7 ms (pro zápisy) a 5–10 ms (pro čtení). Můžete setkat s latencemi podobnými těmto hodnotám. Latence pro spravovanou instanci Azure SQL pro obecné účely jsou podobné. Pokud je vaše aplikace na latence V/V velmi citlivá, zvažte úrovně Pro důležité obchodní informace.

Prozkoumejte skript T-SQL úlohy order_rating_insert_single.sql. Každý z nich INSERT je jedno potvrzení transakce, které vyžaduje vyprázdnění transakčního protokolu.

Jedno potvrzení pro každé vložení není efektivní, ale na aplikaci to nemělo na místní jednotce SSD vliv, protože každé potvrzení bylo velmi rychlé. Cenová úroveň Pro důležité obchodní informace (cíl služby nebo SKU) poskytuje místní jednotky SSD s nižší latencí. Je možné, že existuje optimalizace aplikace, takže úloha není tak citlivá na latenci vstupně-výstupních operací transakčního protokolu.

Dávku T-SQL pro úlohu můžete změnit tak, aby obtékání BEGIN TRAN/COMMIT TRANINSERT iterací.

Spuštění upravené efektivnější úlohy

Proveďte úpravy skriptů a spusťte je, abyste viděli efektivnější výkon V/V. Upravenou úlohu najdete ve skriptu order_rating_insert.sql .

Připravte skript úlohy úpravou order_rating_insert.cmd tak, aby používal správný název serveru a heslo.
Upravené úlohy spusťte pomocí skriptu order_rating_insert.cmd , podobně jako jste spustili předchozí skript úlohy.

Sledování nových výsledků

V SSMS se podívejte na výsledky skriptu T-SQL sqlrequests.sql. Všimněte si mnohem menšího počtu čekání WRITELOG a celkově mešní doby čekání.

Úloha teď běží v porovnání s předchozím spuštěním mnohem rychleji. Toto je příklad optimalizace aplikace pro dotazy SQL, které poběží uvnitř nebo mimo Azure.

Poznámka:

Tato úloha může běžet ještě rychleji u instance služby Azure SQL Database s typem připojení Přesměrovat . Nasazení, které jste v tomto cvičení provedli, používá výchozí typ připojení, což je typ proxy serveru, protože jste připojení mimo Azure. Připojení typu Přesměrovat může takovouto úlohu významně zrychlit vzhledem k menšímu počtu nutných cest z klienta na server a zpět.
Sledujte dobu trvání úlohy. Úloha poběží tak rychle, že může být obtížné sledovat diagnostická data z dotazů použitých dříve v této aktivitě.

Koncept „dávkování“ může pomáhat většině aplikací, včetně těch, které jsou připojené k Azure SQL.

Tip

Zásady správného řízení prostředků v Azure můžou ovlivnit velmi velké transakce a příznaky budou LOG_RATE_GOVERNOR. V tomto příkladu je sloupec typu char(500) Not Null doplněný mezerami a způsobuje velké záznamy transakčního protokolu. Výkon můžete dále optimalizovat tím, že tento sloupec změníte na sloupec s proměnnou délkou.

V další lekci se dozvíte o inteligentním výkonu v Azure SQL.

Pokračovat

Cvičení – optimalizace výkonu aplikace