Self-signed HTTPS-sajt är sjukt långsam
 

Teknisk miljö:

OS: Windows 7 (alt. Windows Server 2008)
Databas: MSSQL 2008
Webben: Asp.NET MVC 3

• I utvecklingsmiljön ligger databasen och webbsajten på samma burk, en Intel i7 Quad-core med 8 GB RAM. I testmiljön ligger de på olika maskiner med liknande eller bättre hårdvara.
  
  
• Databasfrågorna är profilade och inga av dem är krävande. Dessutom finns det så himla lite data att det omöjligen skulle kunna vara orsaken.
  Efter att ha undersökt om det kan ligger nån olycklig logik i serverkoden är slutsatsen nej, så är inte fallet. Nu kommer jag inte ihåg siffrorna i huvudet men jag kunde inte se något anmärkningsvärt när jag profilerade koden. På min egna dator som är ca 6 år gammal tar den tyngsta sidan högst 300 ms att exekvera.
  
  
• Slår jag av HTTPS blir sajten så snabb som man kan förvänta sig men med HTTPS påslaget är det en helt annan historia. För att få en uppfattning om hur segt det är kan det ibland ta 15 sekunder för servern att leverera en bild eller ett javascript. .NET-koden körs på 300 ms men sedan händer det något som uppenbarligen resulterar i en massa väntetid som såklart inte är önskvärd.

Min slutsats är inte helt oväntat att HTTPS måste vara galet uppsatt på något sätt men hur felsöker man detta vidare?

Ett riktigt long-shot.

Har inte de nya Sandy Bridge-CPU:erna nåt speciellt för kryptering? Kanske något man behöver aktivera i BIOS eller liknande. Eller konfigurera på nåt sätt?

Det är inte så att SSL-handshaken/verifieringen tar en jäkla tid?

@KristianE: Ja, det var ett riktigt long-shot. ;)

@abergman: SSL-handshake vad en bra poäng. Jag har dubbelkollat att keep-alive används så det borde inte vara problemet men jag är å andra sidan inte superbäst på HTTPS.

Jag kan förresten nämna att en kortläsare används för att logga in och att all trafik alltid går över HTTPS. För att utesluta att det är kortläsaren som på något sätt ställer till det har jag testat att logga in på andra sajter som har stöd för samma inloggningsförfarande, t.ex. Skatteverket och Pensionsmyndigheten, och där fungerar det utan problem med samma kombination av webbläsare, kort och kortläsare. Har t.o.m. testat med olika kort och kortläsare.

Skickar med skärmpdumpar på hur det ser ut på klientsidan (Firebug) resp. serversidan (Glimpse). Där ser man inga konstigheter dock (föruom all väntetid i webbläsaren).

Jag sätter en slant på https-handskakningen då jag har samma problem med visualsvn-server.

Jag skulle nog kört WireShark för att analysera:
http://wiki.wireshark.org/SSL

@Westman: Trist. Lovar att skriva en rad eller två om problemet blir löst, hoppas att du gör detsamma.

@SimonP: Har sniffat kommunikationen mellan webbläsaren och servern men känner stor osäkerhet kring hur man ska tolka loggen. Kanske kan du eller nån annan som vet bättre kika en snabbis? Bifogat finns en skärmdump som visar ett litet utdrag men utan att visa någon data. Jag hoppas att det inte behövs.

Ska läsa på lite mer imorrn och se om man blir klokare. Tack för tipsen hittills! :)

Det var ett tag sedan jag satt med projektet men nu har jag kanske fått lite distans till problemet.

Kortläsaren - eller snarare kortet - innehåller ett certifikat som ska innehålla en revokeringslista. Jag tänker mig att det är dessa uppslag som tar tid men jag vet inte riktigt hur jag får fram dem. Tips, någon? Borde jag se dem i TCPView eller Wireshark?

Spontant känns det som att jag behöver fixa något i servermiljön för när man använder kortet för att legitimera sig på andra sajter är det inga problem med att det går slött. Frågan är bara vilken inställning man behöver skruva på...

Det kan vara självsigneringen som ställer till det, eftersom du har genererat en egen CA kan ej klientprogramvaran verifiera certet, detta går att testa om man installerar CA-certet i webbläsaren (även i kortprogramvaran om det finns en separat sådant program). Egentligen borde det synas ett felmeddelande/varning om inte certet kan verifieras, men vissa program struntar i detta.