Wielu programistów pomija program SQL Server Profiler zawarty w SQL Server 2000 i 7.0 jako narzędzie developerskie. Ponieważ jedną z funkcji Profilera jest monitorowanie i raportowanie o różnych poziomach wydajności bazy danych, SQL Server można wykorzystać, by zobaczyć, jak aplikacja WWW współpracuje z serwerem. Profiler może też pomóc analizować efektywność kodu. Można na przykład użyć Profilera, by określić, kiedy aplikacja Web byłaby wydajniejsza, przy równoczesnym używaniu Query Analyzera do wykonywania zapytań i optymalizacji kodów.

Aby utworzyć dane bazowe dla Profilera do analizy komunikacji pomiędzy aplikacją Web a SQL Serwerem, warto na początku przetestować kilka stronic. Należy wybrać narzędzie testujące, które rzeczywiście spowoduje obciążenie aplikacji, a następnie uruchomić Profilera, by przyjrzeć się temu obciążeniu. Warto też sprawdzić ostatnią wersję narzędzia testującego Web Application Stress Tool, na przykład ze strony Microsoft Download Center. Application Center, nowy produkt Microsoftu, także zawiera nową wersję tego narzędzia.

Po uruchomieniu śledzenia za pomocą Profilera warto zapisać wyniki pod łatwo rozpoznawalnymi nazwami, a po przeprowadzeniu kilku testów ponownie porównać wyniki dla każdego z kroków. Można także zapisać wyniki śledzenia i powtórzyć obciążenie później, by móc symulować rzeczywiste obciążenie na bazie danych. Trzeba też pamiętać, że obciążenie powtarzane za pomocą Profilera lub Query Analyzera jest tylko symulacją i może różnić się od obciążenia, jakie wygenerowałaby działająca aplikacja WWW. Poniżej przedstawiam proste testy, które przeprowadziłem, by zilustrować użycie Profilera.

Test 1: Uruchamianie prostego zapytania w skrypcie ASP

Wydruk 1: Database.asp

<%
Function RunWithRS(strSP , strDSN) 
'Response.Write "<br> sql is : " & strsp & "<br>" & "  DSN is " & strDSN & "<br>"
    If strDSN = "" Then
        If modDSN = "" Then
            RunWithRS = -99
        Else
            strDSN = modDSN
        End If
    End If
    Dim rs , cmd 
    Set rs = CreateObject("ADODB.Recordset")
    Set cmd = CreateObject("ADODB.Command")
    cmd.ActiveConnection = strDSN
    cmd.CommandText = strSP
    cmd.CommandType = adCmdText
    rs.CursorLocation = adUseClient
    rs.Open cmd, , adOpenForwardOnly
    Set cmd.ActiveConnection = Nothing
    Set cmd = Nothing
    Set RunWithRS = rs
    Set rs = Nothing
End Function
%>

Przede wszystkim został napisany skrypt ASP (patrz powyższy wydruk Database.asp), zawierający funkcje RunWithRS. Następnie powstał krótki skrypt, FirstData.asp, który wywołuje funkcję RunWithRS i uruchamia zapytanie SQL:

sSQL = "select ckey1,col2 from testtable  where ckey1 = 'a' "

Skrypt FirstData.asp został zainstalowany na dwóch serwerach Web. Serwer 1 był stacją roboczą Windows 2000 z procesorem Pentium 600MHz i 192MB pamięci RAM. Serwer 2 był to Toshiba Tecra (133 MHz Pentium, 144MB pamięci RAM) z Windows 2000 oraz uruchomionym SQL Serverem 7.0.

Uruchomiłem Profiler i po ustawieniu właściwości rozpocząłem śledzenie. A oto wyniki (które wynik zamieszczono na poniższym rysunku): linijka SQL:BatchStarting określa początek wsadowego zapytania SQL, który został uruchomiony z serwera 1, linia SQL:BatchCompleting pokazuje koniec tej operacji.

W pierwszym teście czas trwania był identyczny. Wyniki były takie, jakich można było się spodziewać, ponieważ dostęp do bazy danych z obu systemów powinien pokazać te same czasy dostępu. Jedyną różnicą w teście był serwer Web, który nie wpływał na czas wykonania zapytania.

Test 2: Uruchamianie procedury przechowywanej FirstData2.asp

W drugim teście stworzyłem procedurę przechowywaną za pomocą następujących instrukcji SQL:

CREATE PROCEDURE GetTestDataByKey
@ckey char(1)
AS
SELECT ckey1,col2 FROM testtable WHERE ckey1 = @ckey

Następnie uruchomiłem tą procedurę; wystarczyła zmiana parametru sSQL na:

sSQL = "exec GetTestDataByKey 'a'"

Test 2 trwał 1443 ms, co prawie równa się 1494 ms osiągniętych dla dynamicznego zapytania SELECT z testu 1.

Test 3: Używanie obiektu ADO Command w skrypcie FirstData2.asp

Dla testu 3 użyłem obiektu ADO Command i stworzyłem kolekcję parametrów dla przechowywanej procedury. Wydruk 2 (poniżej) pokazuje funkcję zawierającą kod ADO. Podjąłem obserwację i zapisałem wyniki do pliku trace1.trc. Po uruchomieniu FirstData2.asp, skrypt .asp − zawierający kody ADO z kolekcją parametrów − podał czasy trwania od 1370 ms do 1600 ms. Następnie śledzenie zostało przerwane.

Wydruk 2: Kod ADO dla FirstData2.asp

Function RunSPGetRecord(strSP, sckey)           
        Dim rs, cmd, OutPutParms
        Set rs = Server.CreateObject("adodb.Recordset")
        Set cmd = Server.CreateObject("adodb.Command")
        ' Inicjalizacja obiektów ADO i procedur przechowywanych
        cmd.ActiveConnection = getDSN()
        cmd.CommandText = strSP
        cmd.CommandType = adCmdStoredProc
            cmd.Parameters.Append cmd.CreateParameter("@ckey",adchar,adParamInput, 1,sckey )
        rs.CursorLocation = adUseClient
        rs.Open cmd, , adOpenStatic, adLockReadOnly
        if OutPutParms then OutArray = collectOutputParms(cmd, params)
        Set cmd.ActiveConnection = Nothing
        Set cmd = Nothing
        Set rs.ActiveConnection = Nothing
        Set RunSPGetRecord = rs
End Function

Test 4: Używanie Index Tuning Wizard

W ostatnim teście uruchomiłem narzędzie Profilera − Index Tuning Wizard z menu Tools. By użyć Index Tuning Wizard, w pierwszym oknie należy kliknąć Next. W następnym wybieramy bazę danych, którą będziemy testowali, po czym klikamy przycisk Next. W trzecim oknie pozostawiamy zaznaczone I have a saved workload file i klikamy Next. (Wynik śledzenia można zapisać jako plik SQL lub obciążenia). W następnym oknie należy wybrać plik obciążenia przez kliknięcie przycisku My workload file button, wskazać swój plik i następnie kliknąć Next. W kolejnym oknie wybieramy tylko tę tablicę, którą będziemy testować, i klikamy Next.

Index Tuning Wizard uruchomi obciążenie, które zostało przechwycone z moich obserwacji dotyczących bazy danych i analizowanego obciążenia. Kiedy Wizard zakończył analizy i zasugerował utworzenie indeksu. Jedna z analiz pokazała szacunkowy, 80-procentowy wzrost wydajności! Na ekranie wydajności danych kliknąłem Next. W następnym ekranie kliknąłem Apply changes, a potem Next. W ostatnim ekranie kliknąłem Finish, by zastosować proponowany indeks.

Gdy ponownie uruchomiłem testy z nowym indeksem, Index Tuning Wizard poprawił wydajność przetwarzania dla każdej strony. Jednakże wzrost był około 25-procentowy. Rezultaty były takie same zarówno dla przechowywanej procedury, jak i dla dynamicznego zapytania SQL z testu 1. Kolumna CPU (procesora) była bardziej interesująca. Liczby CPU zarejestrowane przed zastosowaniem indeksu zmieniały się w zakresie od 410 ms do 441 ms po zmianie indeksu, liczby CPU zmalały do 270 ms dla dynamicznego SQL-a i dla przechowywanej procedury zakres od 210 ms do 240 ms. Jak widać, dodanie jednego indeksu w tabeli zdecydowanie zwiększyło wydajność i zmniejszyło obciążenie procesora na serwerze.

Potężne narzędzie do śledzenia

Poruszyłem w tym artykule raczej wąski obszar analizy. Programista może rozpocząć generowanie początkowych analiz wydajnościowych poprzez testowanie paru stron (nawet sztucznie stworzonych), tak jak ja to zrobiłem. Następnie będzie mógł użyć Profilera, by bardziej zagłębiać się w swoje aplikacje Web-owe i przyglądać ich aktywności dokładniej. Na przykład może przechwycić inne, różne rodzaje ważnych statystyk dla każdego kroku, który SQL Serwer przechodzi podczas wykonywania twojego zapytania SQL lub przechowywanej procedury. Trzeba też zapamiętać, że stosowanie polecanych indeksów we własnej bazie danych może znacznie poprawić wydajność. Więcej informacji o Profilerze można znaleźć w artykule Itzik Ben-Gan, Trace That Event with SQL Server Profiler, April 2000; Paul Burke, Using SQL Profiler, July 1999; Brian Moran, What? You Still Aren't Using SQL Profiler? dostępnym online na stronie SQL Magazine, numer InstantDoc 16122.

• Uruchamianie prostego zapytania w skrypcie ASP
• Uruchamianie procedury przechowywanej FirstData2.asp
• Używanie obiektu ADO Command w skrypcie FirstData2.asp
• Używanie Index Tuning Wizard
• Potężne narzędzie do śledzenia