Jag vill tipsa om ett plugin till iis 7.5 som heter application warm-up.

Varje gång man laddar upp nya filer, ändrar web.config eller en application pool recycle så måste koden kompileras om. På grund av det så tar det alltid extra lång tid för den första requesten direkt efter en uppladdning exempelvis. När man har flera webbservrar och behöver göra underhåll så kommer det också att ta extra lång tid för den första requesten efter att man släppt på trafik igen.

Detta är givetvis inte bra eftersom användarna drabbas och upplever sidan som långsam.

Ett annat problem kan vara om man har en byggserver som bygger x gånger per dag, och när man vill gå in där för att testa så får man vänta några sekunder innan sidan visas. Det är givetvis irriterande.

Med application warm-up kan du se till att alltid ha förkompilerade sidor.
Exempelvis kan man aktivera så den alltid kompilerar direkt efter varje recycle. Utöver det kan man själv specificera tidpunkter och/eller sidor man vill att application warm-up skall anropa. Kanske har man en tung sida som normalt ligger cachad länge, men första gången sidan laddas så tar det 10 sekunder att läsa in all data till cachen. Då kan man låta pluginet göra det, istället för att användarna skall behöva vänta den tiden.

Jag skriver mest om webbrelaterad säkerhet på denna blogg, men nyligen satt jag och labbade med att försöka logga in på windows med smarta kort. Jag tyckte det var onödigt komplicerat, så för andra som vill prova detta vill jag dela med mig av hur jag gjorde för att komma igång.

Innan man kan börja behöver man en del hårdvara. Jag valde att köpa kort och kortläsare från gemalto och då deras gemalto .net-kort. De går att köpa exempelvis från smartjac.

När jag kopplade in kortläsaren i min windows 7-maskin så hittade den drivrutiner direkt. Men den hittade inga drivrutiner till kortet. För att hitta rätt drivrutiner lät jag bara kortet sitta i, gå till windows update och där tipsade den om drivrutiner till mitt kort. När klienten nu är klar är det dags att ge sig på servern.

För att få lite struktur så skapar jag först en grupp (SmartCardUsers) i active directory som skall kunna logga in med smart card. Det gör att det är väldigt enkelt att bara stoppa in nya användare efterhand.

För att få smarta kort att fungera måste man ha en tjänst som kan utfärda certifikat. I windows server 2008 heter den rollen active directory certificate services (ADCS) och det är alltså den du måste installera.

Man styr hur smarta kort skall hanteras genom GPO (adminstrative tools -> group policy management). De ändringar man behöver göra för att komma igång är att först och främst konfigurera så att GPOn endast appliceras på den nyskapade gruppen SmartCardUsers. Det gör man genom Security Filtering och lägga dit gruppen och ta bort de andra.

Jag vill att alla användare som finns i gruppen automatiskt skall få sitt certifikat efter att de loggar in. En guide startar som kopierar certifikatet till kortet. För att aktivera det gick jag in i Group Policy Management och inställningen User configuration -> Policies -> Windows settings -> Security settings -> Public key policies -> certificate services client – auto-enrollment. Jag aktiverar den och kryssar i ”renew expired certificates” och ”update certificates”.

För att administrera ADCS som vi installerade tidigare använder man administrative tools -> certification authority. Där väljer jag att högerklicka på certificate templates och manage. Letar upp smartcard user och tar duplicate. Jag visar skärmdumpar på de ändringar jag har gjort, i övrigt är det standard. Observera att dessa inställningar gäller för gemalto.net, om du har ett annat kort kan du behöva göra vissa ändringar.

Den sista inställningen vi behöver göra på mallen är att bestämma vilka användare/grupper som skall kunna göra vad. I mitt exempel har jag konfigurerat gruppen gruppen SmartCardUsers att de får läsa mallen, samt använda den för enroll och autoenroll. Vilket då betyder att det kan rullas ut automatiskt till klienten.

Nu återstår det bara att aktivera mallen genom att högerklicka på certificate templates -> new -> certificate template to issue och sedan välja den nya mallen.

Du kan nu välja att uppdatera GPO-inställningarna hos klienten genom att köra ”gpupdate /force” på klienten. Vid nästa inloggning bör en wizard starta som skriver certifikatet till kortet. Om den inte startar kan du prova att starta om certificate authority-tjänsten.

När allt nu är igång och fungerar så finns det mängder av inställningar att göra, exempelvis att användarna endast skall kunna logga in med smarta kort och inte via exempelvis lösenord. Det kan också vara bra att ställa in så att användarna blir utloggade om de plockar ut sitt smarta kort ur kortläsaren.

Om du vill gå in lite mer på djupet och kanske implementera smarta kort på allvar kan jag tipsa om ett bra dokument från microsoft.

Antixss är ett bra säkerhetsbibliotek för att undvika problem med xss. Jag vill här visa hur du kan använda antixss i kombination med lite egen kod för att kunna styra vilka taggar som skall få visas på sidan och inte. Exempelvis kanske man vill tillåta <img>-taggen men inte <div> eller <font>.

När antixss släpptes i version 3.1 kom även en rad nyheter. Bland annat Security Runtime Engine (SRE) som är en http modul som du helt enkelt lägger in i ditt asp.net projekt, konfigurerar att den skall skydda dina sidor och då får du direkt ett bra skydd mot xss-attacker.

Jag vill gärna kunna vara mer flexibel och exempelvis skydda bara delar av en sida. Det är också möjligt med antixss version 3.1 genom metoderna GetSafeHtml() och GetSafeHtmlFragment().

Det fina med GetSafeHtml är att den tar bort all eventuell skadlig kod, men förutom det så åtgärdar den även så all html blir korrekt.
Om vi exempelvis skickar in </div></div></div> till GetSafeHtml, så kommer den att returnera <div></div><div></div><div></div>. Detta gör den givetvis eftersom innehållet från en textbox kanske presenteras mitt i en sida bland andra div-element, vilket annars hade kunnat förstöra den övriga designen. Ett annat exempel är att den gör om <p><div></div></p> till <p></p><div></div><p></p>, detta eftersom en <p>-tagg inte kan innehålla en div.

Det jag tycker är synd med GetSafeHtml är att man inte själv kan konfigurera vilka taggar som skall skrivas ut som vanlig html-kod och vilka som skall köras genom HtmlEncode(). Jag satt precis med en uppgift där jag behövde den funktionen.

Lösningen blev att jag först kör HtmlEncode på alla taggar förutom de som explicit skall vara tillåtna. När det är gjort kör jag GetSafeHtml på det resultatet. Jag använder mig av reguljära uttryck för att välja ut html-taggarna.

I mitt exempel nedan kommer den att skriva ut taggarna <div>,<img> och <br> med attribut på ett säkert sätt.

String data = "exempeltext."; //Hämta data från valfri källa.

//Endast dessa taggar skall skrivas ut som html-kod, alla andra taggar skall
//säkras via HtmlEncode()
String tags = "div|img|br";
String pattern = String.Concat(@"<(?!/?(", tags, @")( .*?|>)).*?>");

//Hämtar alla taggar som inte finns med i tags-variabeln
MatchCollection mc = Regex.Matches(data, pattern, RegexOptions.IgnoreCase);
foreach (Match match in mc)
{
    //Kör HtmlEncode på de taggar som hämtades med det reguljära uttrycket.
    data = data.Replace(match.Value, AntiXss.HtmlEncode(match.Value));
}

data = AntiXss.GetSafeHtml(data); //Kör GetSafeHtml på alla taggar som är kvar i vanlig html-form

Detta är del 3 av 3 i en serie om att lösa prestandaproblem i sql-server.
Del 1 går igenom hur man letar upp prestandaproblem med profiler, del 2 går igenom DMV och del 3 går igenom performance monitor.

Perfmon

Förutom profiler och DMV:er är det bra att köra perfmon för att övervaka hur servern mår. Här kan man ofta på hårdvarunivå bättre identifiera var prestandaproblemen ligger.
Jag går igenom ett antal olika räknare (performance counters) och beskriver hur de skall läsas av och vad rimliga värden är.

De räknare som jag tycker är viktiga att övervaka på en sql-server-databas är följande
Memory: Pages/sec
Physical Disk: Avg. Disk Queue Length
Physical Disk: Avg. Disk Sec/Read
Physical Disk: Avg. Disk Sec/Write
Processor: % Processor Time
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections

Memory: Pages/sec
Denna räknare visar hur mycket som går in eller ut från minne till disk. Du vill att denna räknare skall hålla sig under 20. Om den har ett snittvärde över 20 över en tidsperiod på 5 minuter så behöver du köpa mer minne till servern, alternativt konfigurera om din server och tilldela mer minne via sql-server-konfigurationen. Det är vanligt att man har toppar över 20 och det är helt normalt, det som är viktigt är att snittet inte går över 20.

Physical Disk: Avg. Disk Queue Length
Denna räknare visar hur mycket kö det är mot dina diskar. Denna räknare finns även som läs- respektive skrivvariant som då endast visar hur mycket läs- eller skrivkö det är. De räknarna heter. Physical Disk: Avg. Disk Read Queue Length och Physical Disk: Avg. Disk Write Queue Length. Men de räknarna kan man börja använda först om man ser att man har ett övergripande problem.
De flesta brukar säga att man har diskproblem om räknaren är över 2, men jag tycker nog att man börjar se problem redan när den överstiger 1-1½. Här kommer det också att bli toppar, exempelvis när den gör en checkpoint. För denna räknare gäller även att den i snitt över en tidsperiod på 5 minuter inte skall överstiga 2, alternativt 1-1½ om du väljer att gå på min linje.

Det som är viktigt med denna räknare är dock att den måste beräknas, beroende på hur många diskar du har i ditt system. Om du exempelvis får att snittvärde för avg. disk queue length på ditt system är 7 och du har 10 diskar i ditt system så blir det alltså 7/10=0.7 vilket är mindre än 2 och alltså bör du inte ha några stora diskproblem. Oavsett raid-typ skall du alltid dela på antal diskar i systemet.

Om du vill räkna ut hur många IOs du har per disk skall du använda olika algoritmer beroende på vilken raid-typ.
Raid 0 — I/Os per disk = (reads + writes) / antal diskar
Raid 1 — I/Os per disk = (reads + (2 * writes)) / 2
Raid 5 — I/Os per disk = (reads + (4 * writes)) / antal diskar
Raid 10 — I/Os per disk = (reads + (2 * writes)) / antal diskar

reads får du fram genom räknaren Physical Disk: Avg. Disk Reads/Sec, writes får du fram genom räknaren Physical Disk: Avg. Disk Writes/Sec.

Avg. Disk Sec/Read
Denna räknare talar om hur många sekunder i snitt det tog för disksystemet att returnera data.
Här brukar man säga att
Mindre än 10 ms – mycket bra
Mellan 10 – 20 ms – okej
Mellan 20 – 50 ms – långsamt, kan behöva tillsyn
Större än 50 ms – stora I/O-problem

Avg. Disk Sec/Write
Denna räknare talar om hur många sekunder i snitt det tog för disksystemet att skriva ner data. Här gäller samma avläsningsstrategi som för Avg. Disk Sec/Read.

Processor: % Processor Time
Talar om hur mycket processorlast du har. Processorlasten bör inte överstiga 80%, om den gör det så tyder det på att processorn är överbelastad och att du bör utöka med fler eller snabbare processorer.

SQL Server Buffer: Buffer Cache Hit Ratio
Denna talar om hur ofta sql-server går mot minnet istället för mot disk. I ett OLTP-system vill du att detta värde skall vara över 99% och absolut inte under 90%. Om den är under 90% så bör du köpa mer minne direkt. Om den är under 99% så bör du fundera på om mer ram kan hjälpa till, exempelvis genom att granska fler minnesräknare.

SQL Server General: User Connections
Denna talar om hur många användaranslutningar som finns mot sql-server. Denna bör vara under 255 om du använder standardinställningen på Maximum Worker Threads i sql-server, eftersom den är 255. Om du har fler user connections än 255 bör du öka Maximum Worker Threads till ett värde som är högre än ditt högsta antal user connections. Om user connections är fler än Maximum Worker Threads så kommer sql-server att dela på trådar för varje anslutning vilket kan ge sämre prestanda. Notera dock att beroende på om du kör connection pool så kan många anslutningar ligga vilandes, så många gånger har man kanske fler användaranslutningar än vad sql-server egentligen behöver hantera.

Det är dags att göra en undersökning, jag startar med en där jag själv har bytt åsikt från och till.
Det går att välja flera alternativ och även lägga till alternativ om man saknar något.

Hoppas ni vill vara med att svara, skicka gärna frågan vidare till andra.

Detta är del 2 av 3 i en serie om att lösa prestandaproblem i sql-server.
Del 1 går igenom hur man letar upp prestandaproblem med profiler, del 2 går igenom DMV och del 3 går igenom performance monitor.

DMV

I och med sql-server 2005 och introduktionen av DMV, dynamic management views så har det blivit enklare att lösa prestandaproblem. Med sql-server 2008 utökades antal DMV:er vilket ger ytterligare möjligheter att direkt få reda på var prestandaproblemen ligger.
Jag listar här några bra och användbara DMV:er som fungerar i både sql-server 2005 och sql-server 2008. De flesta kommer from glenn berry eller microsoft.

Hitta alla index som inte använts sedan senaste omstarten av sql-server

Oanvända index vill vi inte ha eftersom det försämrar skrivprestanda

SELECT   OBJECT_NAME(object_id),
         i.name,
         i.index_id as index_id
FROM     sys.indexes i
WHERE    i.index_id NOT IN (SELECT s.index_id
                            FROM   sys.dm_db_index_usage_stats s
                            WHERE  s.object_id = i.object_id
                                   AND i.index_id = s.index_id
                                   AND database_id = DB_ID())
ORDER BY OBJECT_NAME(object_id) ASC

Top 20 frågor som genererar mest cpu

SELECT   TOP 20 qt.TEXT                                     AS 'SP Name',
                qs.total_worker_time                        AS 'TotalWorkerTime',
                qs.total_worker_time / qs.execution_count   AS 'AvgWorkerTime',
                qs.execution_count                          AS 'Execution Count',
                ISNULL(qs.execution_count / DATEDIFF(SECOND,qs.creation_time,GETDATE()),
                       0) AS 'Calls/Second',
                ISNULL(qs.total_elapsed_time / qs.execution_count,
                       0) AS 'AvgElapsedTime',
                qs.max_logical_reads,
                qs.max_logical_writes,
                DATEDIFF(MINUTE,qs.creation_time,GETDATE()) AS 'Age in Cache'
FROM     sys.dm_exec_query_stats AS qs
         CROSS APPLY sys.DM_EXEC_SQL_TEXT(qs.sql_handle) AS qt
WHERE    qt.dbid = DB_ID() -- Filter by current database
ORDER BY qs.total_worker_time DESC

Top 20 frågor som genererar mest logical reads (minne)

SELECT   TOP 20 qt.TEXT                                                          AS 'SP Name',
                total_logical_reads,
                qs.execution_count                                               AS 'Execution Count',
                total_logical_reads / qs.execution_count                         AS 'AvgLogicalReads',
                qs.execution_count / DATEDIFF(SECOND,qs.creation_time,GETDATE()) AS 'Calls/Second',
                qs.total_worker_time / qs.execution_count                        AS 'AvgWorkerTime',
                qs.total_worker_time                                             AS 'TotalWorkerTime',
                qs.total_elapsed_time / qs.execution_count                       AS 'AvgElapsedTime',
                qs.total_logical_writes,
                qs.max_logical_reads,
                qs.max_logical_writes,
                qs.total_physical_reads,
                DATEDIFF(MINUTE,qs.creation_time,GETDATE())                      AS 'Age in Cache',
                qt.dbid
FROM     sys.dm_exec_query_stats AS qs
         CROSS APPLY sys.DM_EXEC_SQL_TEXT(qs.sql_handle) AS qt
WHERE    qt.dbid = DB_ID() -- Filter by current database
ORDER BY total_logical_reads DESC

Top 20 frågor som genererar mest physical reads (I/O)

SELECT   TOP 20 qt.TEXT                                                          AS 'SP Name',
                qs.total_physical_reads,
                qs.total_physical_reads / qs.execution_count                     AS 'Avg Physical Reads',
                qs.execution_count                                               AS 'Execution Count',
                qs.execution_count / DATEDIFF(SECOND,qs.creation_time,GETDATE()) AS 'Calls/Second',
                qs.total_worker_time / qs.execution_count                        AS 'AvgWorkerTime',
                qs.total_worker_time                                             AS 'TotalWorkerTime',
                qs.total_elapsed_time / qs.execution_count                       AS 'AvgElapsedTime',
                qs.max_logical_reads,
                qs.max_logical_writes,
                DATEDIFF(MINUTE,qs.creation_time,GETDATE())                      AS 'Age in Cache',
                qt.dbid
FROM     sys.dm_exec_query_stats AS qs
         CROSS APPLY sys.DM_EXEC_SQL_TEXT(qs.sql_handle) AS qt
WHERE    qt.dbid = DB_ID() -- Filter by current database
ORDER BY qs.total_physical_reads DESC

Top 20 frågor som genererar mest writes (I/O)

SELECT TOP 20 qt.text AS 'SP Name', qs.total_logical_writes, qs.total_logical_writes/qs.execution_count AS 'AvgLogicalWrites',
    qs.total_logical_writes/DATEDIFF(Minute, qs.creation_time, GetDate()) AS 'Logical Writes/Min',
    qs.execution_count AS 'Execution Count',
    qs.execution_count/DATEDIFF(Second, qs.creation_time, GetDate()) AS 'Calls/Second',
    qs.total_worker_time/qs.execution_count AS 'AvgWorkerTime',
    qs.total_worker_time AS 'TotalWorkerTime',
    qs.total_elapsed_time/qs.execution_count AS 'AvgElapsedTime',
    qs.max_logical_reads, qs.max_logical_writes, qs.total_physical_reads,
    DATEDIFF(Minute, qs.creation_time, GetDate()) AS 'Age in Cache',
    qs.total_physical_reads/qs.execution_count AS 'Avg Physical Reads', qt.dbid
    FROM sys.dm_exec_query_stats AS qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
    WHERE qt.dbid = db_id() -- Filter by current database
    ORDER BY qs.total_logical_writes DESC

En lista på index som har fler writes än reads.

När ett index har fler skrivningar än läsningar så kan det tyda på ett dåligt val av index.

SELECT   OBJECT_NAME(s.object_id)                                AS [Table Name],
         i.name                                                  AS [Index Name],
         i.index_id,
         user_updates                                            AS [Total Writes],
         user_seeks + user_scans + user_lookups                  AS [Total Reads],
         user_updates - (user_seeks + user_scans + user_lookups) AS [Difference]
FROM     sys.dm_db_index_usage_stats AS s WITH (NOLOCK)
         INNER JOIN sys.indexes AS i WITH (NOLOCK)
           ON s.object_id = i.object_id
              AND i.index_id = s.index_id
WHERE    OBJECTPROPERTY(s.object_id,'IsUserTable') = 1
         AND s.database_id = DB_ID()
         AND user_updates > (user_seeks + user_scans + user_lookups)
         AND i.index_id > 1
ORDER BY [Difference] DESC,
         [Total Writes] DESC,
         [Total Reads] ASC;

Läs del tre om performance monitor.

Google har regelbundet utökat listan med användbara program sedan de lanserade google speed. Om du har missat det så är det dags att göra ett nytt besök.

Det är riktigt kul att se att de inte bara tipsar om sina egna program utan låter även andra stora företag vara med samt bidrag från vanliga användare.

Några av de intressanta är:

hammerhead – hjälper dig att mäta laddtider på din hemsida
mon.itor.us – övervakar din hemsida och rapporterar om den skulle ligga nere, kan även installeras internt på dina servrar för att övervaka exempelvis cpu eller minne.
SpriteMe! – gör om flera bilder till en enda bild och placerar ut dem via css (css sprites). Det gör att klienten behöver göra färre requests.
oocss – strukturera din css

När sajten går långsamt och orsaken är databasen kan man givetvis lösa problemet genom att köpa mer och/eller snabbare hårdvara. Ett billigare och enklare alternativ som man skall prova först är att undersöka om det går att optimera det befintliga på något sätt. Exempelvis genom att skapa eller modifiera index, skriva om lagrade procedurer eller denormalisera tabeller för att få bättre prestanda. I dessa inlägg beskriver jag fyra användbara sätt att identifiera var flaskhalsen finns och därigenom också veta hur problemet bäst skall lösas.

Jag har valt att dela upp inlägget i tre delar, de andra delarna publiceras de närmsta dagarna.
Del 1 går igenom hur man letar upp prestandaproblem med profiler, del 2 går igenom DMV och del 3 går igenom performance monitor.

Profiler

Profiler är ett verktyg som kan logga allt som händer i databasen. Man kan välja vilka händelser och vilken data (kolumner) som skall loggas.

Identifiera frågor som tar lång tid att exekvera

Det är mycket enkelt att ta reda på vilka frågor som tar lång tid att köra. I mitt exempel kommer jag att logga alla frågor som tar längre tid än 1 sekund att köra. Det brukar generellt vara en bra start. Om frågan tar lång tid att köra så genererar den förmodligen mycket IO och/eller CPU vilket gör frågan till en bra optimeringskandidat.
Börja med att starta sql-server profiler.

1. Välj ”new trace”.
2. Välj ”standard” template.
3. Ta bort alla events förutom RPC:Completed och SQL:BatchCompleted.
4. Kontrollera att kolumnerna textdata, cpu, reads, writes, duration är ikryssade.
5. Klicka på kolumnen duration och mata in 1000 för ”greater than or equal”.
6. Klicka på ”run” och låt den köra en stund

Relativt snart, beroende på hur ofta dina tunga frågor körs, bör du se data i fönstret. Om du inte får någon data kan det hända att alla dina frågor redan exekveras snabbare än 1 sekund, då kan du prova med 500ms eller 250ms.

Identifiera frågor som tar mycket IO

Det tidigare sättet identifierar enskilda frågor som tar lång tid att köra. Det är dock ännu vanligare att en fråga är relativt snabb men körs väldigt ofta och därmed tar väldigt mycket resurser från servern. För att hitta dessa frågor så loggar man alla frågor med profiler, sparar ner all data i en tabell och ställer frågor mot den. I vårt fall grupperar man på TextData-kolumnen som då innehåller hela sql-uttrycket.
Starta sql-server profiler.

1. Välj ”new trace”.
2. Välj ”standard” template.
3. Ta bort alla events förutom RPC:Completed och SQL:BatchCompleted.
4. Kontrollera att kolumnerna textdata, cpu, reads, writes, duration och starttime är ikryssade.
5. Klicka på textdata, mata in exec sp_reset_connection i not like.
6. Klicka på ”run” och låt den köra en stund. Gärna 24h, men beroende på trafikmängd kan det räcka med 1h. Har du färre än 100 000 poster efter 1h kan du köra ett tag till.

När du har samlat tillräckligt mycket data så skall du spara ner det i en tabell ”file -> save as -> trace table”.
I det nedanstående kodexemplet jag har har jag döpt min tabell till trace.

Mitt kodexempel bygger på att det endast är lagrade procedurer som körs. Men om du har ”vanliga” sql-frågor, kanske genererade av en ORM såsom nHibernate så måste du tvätta din trace på motsvarande sätt. Det jag gör nedan är att rensa bort allt förutom namnet på de lagrade procedurerna. Så om ett anrop såg ut såhär

exec myaccount.mystoredprocedure @Username = ‘patrikc’
så kommer det efter tvätten att endast vara myaccount.mystoredprocedure
Fört efter tvätten kan jag gruppera mina lagrade procedurer och få fram vilka procedurer som är mest kostsamma.

--rensa bort exec, hämta endast de poster som börjar på exec.
SELECT
	SUBSTRING(CAST(textdata AS VARCHAR(MAX)),CHARINDEX('exec ',CAST(textdata AS VARCHAR(MAX))) + 5, LEN(CAST(textdata AS VARCHAR(MAX))) - CHARINDEX('exec ',CAST(textdata AS VARCHAR(MAX))) - 4) AS textdata,
	cpu,
	reads,
	writes,
	duration
INTO
	#trace
FROM
	trace
WHERE
	CAST(textdata AS VARCHAR(MAX)) LIKE 'exec%' 

--vissa sps körs med sp_executesql så här raderar jag helt enkelt den informationen.
SELECT
	REPLACE(textdata,'sp_executesql N''EXEC ','') AS textdata,
	cpu,
	reads,
	writes,
	duration
INTO
	#trace2
FROM
	#trace 

--rensa bort allt efter det första mellanslaget (om det finns något mellanslag). gör en union mot de poster som saknar mellanslag.
SELECT
	SUBSTRING(textdata,1,CHARINDEX(' ',textdata) - 1) AS textdata,
    cpu,
    reads,
    writes,
    duration
INTO
	#trace3
FROM
	#trace2
WHERE
	CHARINDEX(' ',textdata) > 0
UNION ALL
SELECT
	textdata,
    cpu,
    reads,
    writes,
    duration
FROM
	#trace2
WHERE
	CHARINDEX(' ',textdata) = 0 

--hämtar tiden som tracen kördes (används för att beräkna antal exekveringar per sekund)
DECLARE  @runtime REAL
SELECT
	@runtime = DATEDIFF(SECOND,MIN(starttime),MAX(starttime))
FROM
	trace

--grupperar alla poster på textdata och summerar cpu, reads, writes, duration. Sorterar på de poster med mest reads.
SELECT
	textdata,
	COUNT(0)                                             AS execcount,
	(CAST(COUNT(0) AS REAL) / CAST(@runtime AS REAL))    AS execpersec,
    SUM(duration)                                        AS sumduration,
    SUM(CAST(duration AS REAL)) / CAST(COUNT(0) AS REAL) AS avgduration,
    MAX(duration)                                        AS maxduration,
    SUM(reads)                                           AS sumreads,
    AVG(CAST(reads AS REAL))                             AS avgreads,
    MAX(reads)                                           AS maxreads,
    SUM(CAST(reads AS REAL)) / @runtime                  AS readspersec,
    SUM(writes)                                          AS sumwrites,
    AVG(CAST(writes AS REAL))                            AS avgwrites,
    MAX(writes)                                          AS maxwrites,
    SUM(CAST(writes AS REAL)) / @runtime                 AS writespersec,
    SUM(cpu)                                             AS sumcpu,
    AVG(CAST(cpu AS REAL))                               AS avgcpu,
    MAX(cpu)                                             AS maxcpu,
    SUM(CAST(cpu AS REAL)) / @runtime                    AS cpupersec
FROM
	#trace3
GROUP BY
	textdata
ORDER BY
	SUM(reads) DESC

Anledningen att jag väljer att i första hand sortera på de poster med mest reads är att det i de flesta fall är de som tar mest resurser från servern. Om man får ner de största posterna på reads så kan exempelvis duration gå ner på andra frågor, just eftersom diskköerna har gått ner.

Läs del två om DMV.

Det är inte sällan man läser om sajter som har blivit hackade där det ofta visat sig att lösenorden varit lagrade i klartext. Förutom det uppenbara problemet med att hackaren kan logga in på den berörda tjänsten med vilken användare som helst och möjlighet att förstöra, så skapar det indirekt problem även för andra tjänster på internet. På grund av att användarna ofta använder samma lösenord för olika tjänster så kan en hacker exempelvis prova samma lösenord på andra tjänster, såsom gmail och hotmail och därmed ta över användares e-postadress också.

För att minska risken för ovanstående så skall sajtägare givetvis jobba för att få användare att ha olika lösenord. Det andra är att man som sajtägare skall ta sitt ansvar och skydda sina användares lösenord på ett bra sätt, och det är det jag skriver om i detta inlägg.

De komponenter som jag brukar förespråka skall finnas i ett bra lösenordssystem är: lösenord, hashfunktion, systemsalt, användarsalt, sammansättning, iterationer och versionshantering. Jag går igenom varje del för sig. Jag kommer i varje del beskriva varför det behövs.

Lösenord

Ditt lösenordssystem bör hjälpa användarna att välja ett bra lösenord. Sätt exempelvis krav på att lösenordet måste innehålla minst 8 tecken, varav minst en siffra och en icke alfanumerisk. Tänk på att kontrollera lösenordet både på klientsidan och serversidan. Läs gärna mitt inlägg om avancerade reguljära uttryck för att se exempel på hur det kan lösas. Kontrollera att lösenordet inte är samma som delar av e-postadress eller användarnamn.
I samband med att användaren väljer lösenord bör du visa en hjälptext för användaren hur man väljer ett bra lösenord. Hjälptexten kan exempelvis innehålla:

• Välj ett lösenord som är svårt att gissa sig till
• Välj ett lösenord som inte kan kopplas till dig eller någon annan familjemedlem exempelvis via namn, datum, smeknamn
• Välj ett unikt lösenord som du inte använt på någon annan sajt

I hjälptexten bör du dock inte ge riktlinjer om vilket lösenord man skall välja, då är risken stor att användaren kommer att skapa ett lösenord efter dina riktlinjer. Hjälptexten bör alltså inte innehålla fraser som:

• Välj ett svårt lösenord, exempelvis: Jua7;s..A’82
• För att komma ihåg ditt lösenord, skapa en mening och ta de första bokstäverna till lösenordet, såsom. ”Jag heter John och är 90 år gammal.”, skulle då bli JhJoä90åg.

Varje del i detta inlägg kommer att utveckla lösenordssystemet och göra det säkrare. Jag vill därför via kod visa hur det kan se ut utan hashning.

password = ”Ha%Ndl3(2~1″; // 11 tecken långt lösenord
userController.SavePassword(password); // lösenordet lagras i klartext

Hashfunktion

Eftersom vi inte vill lagra lösenordet i klartext så vill vi hasha användarens lösenord innan det lagras i databasen. En hashfunktion är så kallad envägskryptering, vilket betyder att det inte går att återskapa originaldatat från den krypterade (eller hashade) strängen. Läs mitt inlägg om hur en hashfunktion fungerar om du vill veta mer.

Du bör använda en så säker hashfunktion som är möjligt i just ditt projekt. Det kan exempelvis vara sha512. md5 och sha1 anses vara osäkra i dag. Det är andra – säkrare – hashfunktioner på gång, såsom sha-3 och skein.

password = ”Ha%Ndl3(2~1″; // 11 tecken långt lösenord
hash = sha512(password); // lösenordet hashas med sha512
userController.SavePassword(hash); // lösenordet kan inte återskapas eftersom det är hashat

Systemsalt

Problemet med att enbart hasha lösenordet är att en eventuell hacker då kan skapa en databas som innehåller hashvärden av alla ord i en ordlista, och om inte det skulle räcka för att knäcka lösenord, så kan en hacker generera alla kombinationer upp till n tecken [a-zA-Z0-9] samt diverse icke alfanumeriska tecken. Det finns redan projekt för detta, exempelvis md5this eller rainbow table som inte ens behöver generera alla kombinationer.

Därför bör man lägga till ett salt som är samma för alla användare. Saltet bör vara långt, gärna över 20 tecken och ha samma krav som ett vanligt lösenord. Alltså bestå av siffror och icke alfanumeriska tecken.

Kodexempel

salt = ”PP’P0M`*4e&5I@}” // långt salt
password = ”Ha%Ndl3(2~1″; // 11 tecken långt lösenord
hash = sha512(salt + password); // skapar hash baserat på lösenord och salt
userController.SavePassword(hash); // lösenordet kan inte återskapas eftersom det är hashat

Användarsalt

Problemet med att enbart hasha och använda systemsalt är att två användare som har valt samma lösenord har samma hashvärde i databasen. Detta kan utnyttjas av en hacker som kommer åt databasen. Exempelvis genom att generera nya användare med unika lösenord. Om den nyskapade användaren har samma hashvärde som en annan användare i databasen så har man knäckt den användarens lösenord.

För att motverka den möjligheten kan vi lägga till ett användarsalt som är unikt för varje användare. Då kommer hashvärdet inte att bli samma även om två användare har valt exakt samma lösenord.

usersalt = ”<4VKfZK.^>KbT\G=sg[U^|Zz7hzfrh]vVA$ORE,b.Lbi42Gwk2flGy23PEOtB.”; // hämta användarsalt exempelvis från databasen
salt = ”PP’P0M`*4e&5I@}” // långt salt
password = ”Ha%Ndl3(2~1″; // 11 tecken långt lösenord
hash = sha512(salt + password + usersalt); // skapar hash baserat på lösenord och salt
userController.SavePassword(hash); // lösenordet kan inte återskapas eftersom det är hashat

Sammansättning

Hur man sätter samman sin hash kan variera. Anledningen till det är att om en hacker exempelvis kommer åt systemsalt och användarsalt så kan det användas för att göra en brute force. Problemet som hackern har är att han inte vet hur hashen är sammansatt. Se mitt kodexempel nedan för två exempel som kommer att resultera i två helt olika hashvärden, trots att alla komponenter systemsalt, lösenord och användarsalt är samma.

hash1 = sha512(salt + password + usersalt); // exempel på en sammansättning
hash2 = sha512(usersalt + password + salt); // exempel på en annan sammansättning
hash3 = sha512(sha512(usersalt + password) + salt); // exempel på en tredje sammansättning
hash4 = sha512(salt + usersalt + sha512(password)); // exempel på en fjärde sammansättning

I de två första sammansättningarna har jag bara valt att byta plats på systemsalt och användarsaltet. Denna enkla förändring gör det dock genast svårare för en hacker att genom brute force få fram användarens lösenord. De två nedre är exempel där jag har valt att först skapa en hash och sedan skapa mitt slutgiltiga hashvärde baserat på den hashen och de återstående värdena.

Iterationer

Om en hacker får tag i hashvärdet, användarsaltet, systemsaltet samt sammansättningen så är det givetvis mycket illa. Men för att hackern skall kunna återskapa lösenord från dessa hashvärden så måste han köra brute force som helt enkelt skapar en hash baserat på alla möjliga kombinationer. När hackern lyckas skapa en hash som motsvarar den som fanns i databasen så har han fått fram lösenordet. Datorer kan prova flera tusen olika lösenord i sekunden, naturligtvis beroende på datorkraft men också på hashfunktion och sammansättning. Man vill försöka få ner antalet lösenord som kan testas per sekund, ett sätt är att lägga till iterationer som helt enkelt hashar lösenordet flera gånger. På det sättet måste även en hacker hasha lösenordet flera gånger vilket då tar processorkraft och i slutändan tar det längre tid för en hacker att göra brute force.

usersalt = ”<4VKfZK.^>KbT\G=sg[U^|Zz7hzfrh]vVA$ORE,b.Lbi42Gwk2flGy23PEOtB.”; // hämta användarsalt exempelvis från databasen
salt = ”PP’P0M`*4e&5I@}” // långt salt
password = ”Ha%Ndl3(2~1″; // 11 tecken långt lösenord
hash = sha512(salt + password + usersalt); // skapar hash baserat på lösenord och salt
for (int i=0;i<1000;i++){
hash = sha512(hash); // skapar ny hash av det föregående hashvärdet
}
userController.SavePassword(hash); // lösenordet kan inte återskapas eftersom det är hashat

I ovanstående exempel hashar jag hashvärdet 1000 gånger. Du kan vilja hasha fler gånger. RSA PKCS #5 rekommenderar minst 1000 iterationer.

Versionshantering

Du vill hela tiden se över ditt lösenordssystem. Kanske använder du en hashfunktion som är gammal och osäker, såsom md5. Eller så vill du ändra sammansättning, systemsalt eller iterationer. Oavsett vad så vill du kunna ändra. Därför är det bra att versionshantera dina användares lösenord. Det innebär att trots att du har bytt lösenordssystem så kan en användare logga in via det gamla systemet och när han gör det så skapar du en ny lösenordshash för användaren och nästa gång användaren loggar in görs det genom det nya lösenordssystemet. En annan fördel med detta är att du efter x dagar/veckor/månader kan stänga av alla användare som inte har uppgraderat sitt lösenord till det nya systemet, om du exempelvis har hittat en säkerhetslucka i ditt system eller om en hacker har gjort det.

passwordVersion = ”1.2″;
userController.SavePassword(hash, passwordVersion); // lösenordet sparas på samma sätt som vi gjort förut men denna gång skickar vi med versionsnummer som också lagras i databasen

Men om användaren glömt lösenordet?

En vanlig fråga som dyker upp i samband med hashning av lösenord, är hur man skall kunna skicka lösenordet till användaren om denna har glömt det. Som jag ser det så skall man aldrig skicka ett lösenord till en användare. Anledningen är lösenordet för det första skall vara hashat och för det andra är det vanligt att lösenordet skickas okrypterat via e-post som ligger lagrat i all evig framtid. Detta gör att om användarens e-post blir hackat och användaren inte har bytt lösenord så kommer hackern åt tjänsten.

Istället rekommenderar jag ett lösenordsåterställningssystem som baseras på två nycklar som är unika för varje användare. Man kan exempelvis skicka en länk (via e-post) som ser ut såhär:
restore_password.aspx?userid=1&key1=1C7D40F0-900B-11DE-AC98-81E455D89593&key2=255D0FFC-900B-11DE-938D-A5E455D89593.
Dessa två nycklar skall endast vara giltiga en viss tid, exempelvis 24 timmar samt bli ogiltiga direkt när användaren har bytt lösenord. Detta tvåkomponentsystem gör det i praktiken väldigt svårt att gissa sig till nycklarna och därmed svårt att hacka.

När användaren följer länken så kommer den till en krypterad sida (https) där han kan välja sitt nya lösenord.

Det finns några intressanta nyheter för utvecklare i sql-server 2008. Jag vill här visa några exempel.

Tilldela värde till variabler redan vid deklarationen

Innan sql-server 2008 var man tvungen att först deklarera en variabel via declare @var int för att sedan tilldela variabeln via set @var = 42. Det har nu blivit möjligt att tilldela ett värde direkt vid deklarationen. Exempelvis.

declare @var int = 42

Mata in flera rader samtidigt i en insert

När man skapar poster i en tabell med insert så har det tidigare krävts ganska mycket kod, varav det mesta varit repetitivt. Man skrev ofta på följande sätt.

insert into mytable values (1, 'first')
insert into mytable values (2, 'second')
insert into mytable values (3, 'third')

Det har nu blivit minte repetitivt genom att man bara behöver skriva insert into mytable values en gång. Nedanstående kod resulterar alltså i tre nya poster i tabellen.

insert into mytable
  values (1, 'first'), (2, 'second'), (3, 'third')

Smidigare tilldelning

Det har länge varit möjligt att öka eller minska en variabels värde genom += eller -= i c#. Nu kommer samma möjlighet i sql. Istället för att skriva.

update mytable set price = price + 10 where product = 'first'

så kan vi nu skriva:

update mytable set price += 10 where product = 'first'

De nya operatorerna är: +=, -=, *=, /= och %=.

Nyheterna som jag beskrivit hittills handlar mycket om att få ner mängden kod som behöver skrivas för att utföra något. Det är inte bara bra för utvecklarna, det är också bra för prestandan eftersom det blir mindre nätverkstrafik.

Bättre datumhantering

Det finns nu fler datatyper för att hantera datum.
Exempelvis finns datetime2 som har en noggrannhet på 100 nanosekunder, exempelvis 2009-08-17 11:14:45.3875725. Detta är att jämföra med datetime vars noggrannhet endast är 3.33 millisekunder, exempelvis 2009-08-17 11:14:45.387.

Förutom ovanstående så finns det två nya datatyper i form av date och time.
Datetime lagras i form av 8 bytes.
Datetime2 lagras med 7 bytes som standard, men kan ta upp till 8 bytes om fler decimaler används.
Date lagras med 3 bytes.
Time lagras med 5 bytes.

Ofta när man jobbar med datum har man ingen användning av tiden, därför är det bra att nu kunna skapa kolumner som bara är datum. Dessutom har det ibland varit problematiskt att hämta ut poster baserat på datum. Detta eftersom sql-server avrundar. Som exempel kan vi ta nedanstående.

CREATE TABLE [DateTest](
	[PostDate] [datetime]
)

INSERT INTO DateTest VALUES
	('2009-08-08 23:59:59'),
	('2009-08-09 00:00:00'),
	('2009-08-10 00:00:00'),
	('2009-08-10 00:00:01')

SELECT * FROM DateTest WHERE PostDate BETWEEN '2009-08-09' AND '2009-08-10'

Ovanstående SELECT resulterar i två poster. Alltså 2009-08-09 00:00:00 och 2009-08-10 00:00:00. Här förväntar vi oss förmodligen att få tre poster där PostDate är antingen 2009-08-09 eller 2009-08-10, men istället får vi alla datum som är mellan eller lika med 2009-08-09 00:00:00 och 2009-08-10 00:00:00 och missar därmed 2009-08-10 00:00:01. Ovanstående har många gånger orsakat buggar i diverse applikationer. Med datatypen date blir det genast enklare.

CREATE TABLE [DateTest](
	[PostDate] [date]
)

INSERT INTO DateTest VALUES
	('2009-08-08 23:59:59'),
	('2009-08-09 00:00:00'),
	('2009-08-10 00:00:00'),
	('2009-08-10 00:00:01')

SELECT * FROM DateTest WHERE PostDate BETWEEN '2009-08-09' AND '2009-08-10'

Ovanstående kod returnerar alla tre poster. Dessutom sparar vi 5 bytes.

Merge

Merge används för att jämföra två datamängder och sedan köra insert/update/delete baserat på vad man har definierat. Det kan exempelvis användas istället för att göra en så kallad UPSERT som kortfattat innebär att man först kontrollerar om posten finns och gör en update eller insert baserat på det. Exempel på en upsert kan vara.

IF EXISTS (SELECT * FROM UPSERTEXAMPLE WHERE name = 'john doe')
BEGIN
	UPDATE UPSERTEXAMPLE SET name = 'john doe 2' WHERE name = 'john doe'
END
ELSE
BEGIN
	INSERT INTO UPSERTEXAMPLE VALUES ('john doe 2')
END

Med merge kan man istället skriva.

MERGE UPSERTEXAMPLE as t --target
USING (SELECT 'john doe' as name) as s --source
ON t.name = s.name
WHEN MATCHED THEN
   UPDATE SET t.name = 'john doe 2'
WHEN NOT MATCHED BY TARGET THEN
   INSERT VALUES(s.name);

Notera att semikolon i slutet är obligatoriskt för merge.
Merge fungerar som så att man först anger ett mål (target) och sedan en källa (source) samt deras relation i form av en join. I vårt fall joinar vi t.name och s.name. Sedan lägger man in ett antal villkor. Om båda posterna finns i både källan och målet så genomförs en update. Om posten inte finns i målet så lägger man till posten med en insert. Vid de prestandamätningar som jag har gjort på merge så är merge långsammare än en upsert. Men om det är flera poster som skall jämföras så blir merge givetvis användbar eftersom den är set-baserad.

Ett annat tillfälle då merge kan vara bra är om man vill synkronisera två tabeller. I mitt exempel har jag två likadana tabeller. Den ena är för produktion, och den andra för utveckling. Det rör sig om en tabell med texter. Om man vill synkronisera dessa tabeller så informationen är identisk kan man göra på följande sätt.

Vi börjar med att skapa tabellerna och mata in exakt samma innehåll.

CREATE TABLE productioncontent (contentkey int primary key, content varchar(max))
CREATE TABLE developmentcontent (contentkey int primary key, content varchar(max))

INSERT INTO productioncontent values (1, 'text'), (2, 'text'), (3, 'text')
INSERT INTO developmentcontent values (1, 'text'), (2, 'text'), (3, 'text')

Sedan gör vi diverse ändringar i produktionstabellen.

INSERT INTO productioncontent values (4, 'text')
UPDATE productioncontent SET content = 'new text' where contentkey = 3
DELETE FROM productioncontent WHERE contentkey = 2

Nu vill vi med merge se till att alla ändringar vi gjorde nyss på produktionstabellen även kommer till utvecklingstabellen.

MERGE developmentcontent as d --target
USING productioncontent as p --source
ON d.contentkey = p.contentkey
WHEN MATCHED AND d.content <> p.content THEN
   UPDATE SET d.content = p.content
WHEN NOT MATCHED BY SOURCE THEN
   DELETE
WHEN NOT MATCHED BY TARGET THEN
   INSERT VALUES(p.contentkey, p.content);

Det som skiljer ovanstående från föregående exempel är att vi endast gör en update när posterna matchar (eftersom vi kör join på contentkey) och content är förändrat. Utöver det gör vi en delete och raderar därmed posten när raden inte matchar i källan (source). Vi utför en insert när posten inte finns i målet (target). Läs gärna mer om merge på microsofts hemsida.

Table valued parameters

Table valued parameters gör det möjligt att skicka in en hel kollektion från .net direkt till sql-server. Tidigare har man behövt köra en insert/update/delete i taget eller skicka in exempelvis en kommaseparerad sträng att jobba vidare med. Förutom enklare hantering i både .net-koden och på databassidan så blir det bättre prestanda eftersom färre databasanrop krävs. Jag har skrivit ett längre blogginlägg om table valued parameters, läs det gärna för att lära dig mer.