Das World Wide Web und wie wir es nutzen hat sich im Laufe seines Daseins verändert. Von einzelnen, statischen Hypertext-Dokumenten hin zu komplexen, interaktiven Seiten voller multimedialer Inhalte. Dies zeigt sich auch in den Statistiken: Seit 2010 hat sich die durchschnittliche Website-Größe (in Desktop-Darstellung) mehr als verdreifacht. Die durchschnittliche Anzahl an Requests pro Seite liegt mittlerweile bei über 80. Dies hat vor allem Auswirkungen auf die Seitenladezeit, aber HTTP/2 schafft Abhilfe!

Mehr Bandbreite, mehr Bandbreite!

Eine höhere Bandbreite wirkt sich auch immer positiv auf die Seitenladezeit aus. Das möchte man meinen, doch die Seitenladezeit (PLT, Page Load time) hat sich in den letzten Jahren, trotz höherer Bandbreiten, kaum verändert hat. Woran liegt das?
Untersuchungen haben gezeigt, dass sich ab einer Bandbreite von 5 Mbit/s nur minimale Verbesserungen der Seitenladezeit feststellen lassen. So resultiert aus einer Verdoppelung der Bandbreite von 5 auf 10 Mbit/s, eine nur um 5% bessere PLT. Einen viel größeren Einfluss hat die Latenz, auf die nur schwer und mit hohem Aufwand Einfluss genommen werden kann. Eine Verringerung der Latenz spiegelte sich also unmittelbar in einer verbesserten PLT wider. Wieso?
Websites und ihre Bestandteile werden über das Hypertext Transfer Protocol (HTTP) geladen, welches das Transmission Control Protocol (TCP) als Transportprotokoll nutzt. Auf Grund verschiedener Eigenschaften von TCP (Reliable Transmission, Retransmission, Congestion Control) ist dessen Performance unmittelbar abhängig von der Latenz des Netzes. Noch deutlicher spürbar in mobilen Netzen, in denen die Latenz stärker schwankt und deutlich höher liegt als über Kabel. Eine Möglichkeit der Abhilfe in Bezug auf die PLT kann also eine optimierte Nutzung der TCP-Verbindungen sein – HTTP/2 macht das möglich!

Von HTTP/1.1 zu 2.0 in „nur“ 20 Jahren

Im Jahr 1997 wurde HTTP/1.1 (RFC2068) als Update der nur ein Jahr zuvor erschienenen Version 1.0 veröffentlicht. Denn es gab Nachbesserungsbedarf: Wie in HTTP/1.0 beschrieben, muss für jeden Request eine neue TCP-Verbindung (short-lived connection) geöffnet werden. Durch den zeitintensiven TCP Three-Way-Handshake und der Nutzung als „Cold Connection“ (TCP Slow Start) führte dies zu starken Performance-Einbußen. In HTTP/1.1 wurde deshalb der keep-alive-Header eingeführt, wodurch eine geöffnete TCP-Verbindung nicht mehr sofort geschlossen wird, sondern für einen bestimmten Zeitraum geöffnet bleibt (persistent connection), sodass sie für weitere Request/Responses genutzt werden kann.

Seitdem hat sich das Web weiterentwickelt, das HTTP-Protokoll erfuhr jedoch für über 20 Jahre hinweg nur wenige Änderungen. Vielleicht war es der Vorstoß von Google mit dem Protokoll SPDY (gesprochen „Spidi“), der neue Bewegung in das Thema brachte. In jedem Fall sind große Teile des Protokolls in die neue Version des HTTP-Protokolls (RFC 7540) eingeflossen. SPDY selbst wurde von Google in Hinblick auf den neuen, kommenden Standard HTTP/2 zurückgezogen und der Support eingestellt.

Was ist neu in HTTP/2?

HTTP/2 ermöglicht eine effizientere Nutzung der Netzwerkressourcen und merzt somit einige Mängel von HTTP/1.1 aus, ohne dabei die Semantik des Vorgängers zu verändern. Dabei sind die folgenden drei Neuerungen ausschlaggebend.

Multiplexing

Ein Problem, das mit HTTP/2 adressiert wird, ist Head-of-line blocking. Dabei stauen sich die ausgehenden Request in einer Warteschlange an, da eine Verbindung immer nur für einen Request/Response gleichzeitig genutzt werden kann. Die Verarbeitung erfolgt also pro Verbindung sequentiell. In HTTP/1.1 wurde bereits versucht mittels HTTP Pipelining dieses Problem zu lösen, leider erfolglos. Stattdessen hilft der Browser, denn dieser verarbeitet Requests durch das Öffnen mehrerer Verbindungen parallel (je nach Browser bis zu 8 pro Hostname). Dennoch erfordern heutige Websites häufig ein Vielfaches der zur Verfügung stehenden gleichzeitigen Verbindungen zum vollständigen Laden.

In HTTP/2 können durch Multiplexing mehrere Request- und Response-Nachrichten parallel über dieselbe TCP Verbindung übertragen werden, wodurch das Öffnen mehrerer Verbindungen nicht mehr notwendig ist. Dadurch werden einige etablierte Workarounds wie Concatenation, CSS-Sprites oder Domain Sharding obsolet.

Header Compression

Durch die Zustandslosigkeit des HTTP-Protokolls ist es notwendig bei jedem Request alle für die Verarbeitung benötigten Informationen mitzusenden. Werden viele Ressourcen desselben Host abgefragt, werden vielfach redundante Header-Informationen übertragen, obwohl der Server diese möglicherweise durch vorangegangenen Requests bereits erhalten hat.
Um dieses Problem zu adressieren, wird ein speziell für HTTP/2 entwickeltes Kompressionsformat namens HPACK angewandt. Vereinfacht sieht dieses vor, dass sowohl Server als auch Client pro Verbindung eine dynamische Lookup-Table für die Header-Informationen halten. Der Client kann den Server dazu anweisen die empfangenen Header-Informationen in seiner Tabelle zu speichern. Muss der Client denselben Header nochmal schicken, sendet er nur den Index des Tabelleneintrags. Zusätzlich sind die Header-Informationen Huffman-kodiert.

Server Push

Fordert der Client eine Seite beim Server an, folgen nach der Analyse der Seite weitere Requests des Clients zur Anforderung benötigter Ressourcen, wie JavaScript-, CSS- oder Bilddateien. Um die Zeit bis alle Ressourcen vorliegen zu verkürzen, kann der Server diese Ressourcen bereits bei Anfrage der Seite mit an den Client schicken, sodass diese dann bereits im Cache des Clients vorliegen und kein weiterer Round-Trip notwendig ist.

Unterstützt mein Browser HTTP/2?

Die meisten Browser-Hersteller haben bereits seit längerem den Support für HTTP/2 implementiert. Eine detaillierte Übersicht findet sich bei caniuse.com. Da HTTP/2 abwärtskompatibel ist, gibt es nichts zu beachten. Das Protokoll wird im Rahmen des ersten Request „ausgehandelt“ (ALPN, Application-Layer Protocol Negotiation).

Kann ich HTTP/2 mit meinem Webserver verwenden?

Ein klares: „It depends!“ Konkret kommt es darauf an, ob der genutzte Webserver bereits HTTP/2 implementiert und die Seitenzugriffe verschlüsselt erfolgen. Die Spezifikation sieht zwar keinen Zwang für Verschlüsselungen wie TLS vor, trotzdem erfordern es die meisten Implementierungen. Eine Liste mit Implementierungen findet sich auf der Github-Seite für HTTP/2 der HTTP Working Group. In der Microsoft-Welt bietet IIS 10 die Unterstützung. Dieser ist allerdings an Windows Server 2016 geknüpft, weshalb sich der ein oder andere bis zum nächsten OS-Update gedulden muss.

Fazit

Mit HTTP/2 wurde die Basis für das Protokoll des WWWs erneuert und es wurde auch Zeit.
In Hinblick auf die Performance lohnt sich die Aktivierung von HTTP/2 vor allem dann, wenn zum Laden der Seiten eine Vielzahl an Ressourcen vom Server abfragt werden muss. Auf Grund der Abwärtskompatibilität zu HTTP/1.1 hat eine Aktivierung aber auch keine negativen Aspekte. Zu berücksichtigen ist die Unterstützung des eingesetzten Webservers. Wir selbst hosten unsere Website als Azure App Service in der Cloud. Eine Umstellung bedeutet hier nicht mehr Aufwand als das Umlegen eines Schalters in der Administrationsoberfläche. Vielleicht auch für Sie ein Anreiz über einen Cloud Move nachzudenken!

In den letzten Jahren hat sich HTTP, dank REST, als eines der wichtigsten Protokolle zur Kommunikation zwischen Web-Services etabliert. Die Verwaltung und Betreuung solcher Services ist eine große Herausforderung. Mit Azure API Management will Microsoft das ändern.

Eine API (Application Programming Interface) beschreibt Operationen, die die Schnittstelle für Kommunikation zwischen Systemen zur Nutzung ihrer Funktionalitäten, vorschreiben.

Die Bereitstellung komplexer APIs stellt für Entwickler und Administratoren viele Herausforderungen dar, die sich stark voneinander unterscheiden und die umfangreiche Kenntnisse erfordern, um diese verwalten zu können. Die Verwaltung einer API befasst sich u.a. mit folgendem:

• Zugriffsteuerung

• Analytik

• Dokumentation für Entwickler

• Ratenbegrenzung

Azure API Management, ist ein Microsoft „Platform as a Service“ (PaaS) zur Lösung oben genannter Aufgaben. Er bietet u.a. einen Proxy zwischen der zu verwaltenden API und Anwendungen, die die Dienste der API nutzen. Durch Azure API Management verwaltete APIs müssen nicht in Azure gehostet werden, sondern können auch on premises oder in anderen Cloud Diensten gehostet werden.

Azure API Management teilt sich in drei Komponenten auf:

• Publisher Portal: Eine Web-Applikation, womit Herausgeber der API unterschiedliche Konfigurationen des Proxys verwalten können.

• Developer Portal: Bietet den Entwicklern eine Web-Applikation, um auf die Dokumentation der API sowie ihre eigenen Monitoring Dienste zuzugreifen.

• API Proxy: Es besteht kein direkter Zugriff auf die API. Client Anwendungen kommunizieren mit dem Proxy zur Weiterleitung der Aufrufe an die API.

Da verschiedene APIs sich des gleichen Geschäftsmodels bedienen können, bietet Azure API Management das Produkt (Products) Konzept an. Ein Produkt stellt den Entwicklern eine Art von Abonnement zur Verfügung, womit verschiedene APIs zusammen verwaltet werden können.

Ein Produkt und seine APIs können durch Richtlinien (Policies) konfiguriert werden.

Die Macht der Richtlinien

Wie oben erwähnt, findet jede Kommunikation zwischen einer API und einer Anwendung, durch den Proxy statt. Dadurch ist es möglich alle Anfragen (Inbound) sowie Antworten (Outbound) vom Proxy abzufangen und je nach Anfrage oder Antwort, zusätzliche Dienste anzubieten.

Diese Richtlinien können innerhalb des Lebenszyklus einer Anfrage ausgeführt werden. Dieser Lebenszyklus  besteht aus 4 Phasen:

1. Inbound: beim Eingang eines Aufrufs.

2. Outbound: beim Ausgang eines Aufrufs (Antwort auf den eingehenden Aufruf).

3. Backend: nach Inbound Richtlinien und bevor die Anfrage an die Backend API geschickt wird.

4. Error: beim Auftritt von Fehlern.

Richtlinien sind XML basiert und können auf Produkte, APIs und Operation angewandt werden. Außerdem unterstützen sie C#-6, womit sich sämtliche Szenarien dynamischer und flexibler verwalten lassen.
Die Abbildung zeigt die Konfigurationsoberfläche für die Richtlinien.

Sollen z.B. die Anfragen aller APIs als XML beantwortet werden, müssen die folgenden Rechtlinie für alle Produkte, APIs und Operationen spezifiziert werden:

Solche Richtlinien sind zustandslos. Mit der vordefinierten Context-Variable ist es aber durchaus möglich auf Anfragen bezogene Informationen und Metadaten zuzugreifen. So kann man z.B. festlegen, dass von einer IP-Adresse maximal 5 Aufrufe pro Sekunde behandelt werden.

Wird ein Endpunkt mehr als 5 Mal innerhalb von 20 Sekunden aufgerufen, erhält man einen Rate Limit-Fehler:

Es ist zu beachten, dass das erste Beispiel eine Outbound-Richtlinie und das zweite eine Inbound-Richtlinie zeigt. D.h. dass, das erste Beispiel auf allen Antworten anzuwenden ist. Beim zweiten sind nur eingehende Aufrufe betroffen.

Innerhalb des „on-error“ Abschnitt, kann man Richtlinien, die beim Auftreten von Fehlern ausgewertet werden, festlegen.  Im folgenden Beispiel wird nach Fehlern, die durch die Auswertung der Ratenbegrenzungsrichtlinie ausgelöst werden, gesucht. Dafür ist von den Ablaufsteuerungselementen wie z.B. „choose“ und „when“ Gebrauch zu machen. Damit lassen sich Antworten modifizieren.

Richtlinien sind nicht nur für die Kommunikation einer Applikation, dem Proxy und der API gedacht. Aufrufe an externe Dienste können z.B. mittels der Richtlinie „send-request“ definiert werden.

In diesem Artikel wurde insbesondere auf das Thema Richtlinien in Azure API Management eingegangen. Eine XML basierte Konfiguration, zur Behandlung und Bearbeitung von Anfragen, welche nicht nur statische Konfigurationen sind. Auch dynamische und flexible Konfigurationen, die sich innerhalb des Lebenszyklus einer Anfrage, auswerten lassen sind möglich und einfach zu gestalten.

Fazit

Vielen lassen sich vom Azure API Management täuschen und stellen es sich als ein weiteres Werkzeug, um APIs in der Cloud zu hosten, vor. Das ist aber nicht der Fall.

Azure API Management stellt ein mächtiges Werkzeug in Azure für den Einsatz, Verwaltung und sogar bis zur Erweiterung dieser APIs. Ob für Administratoren oder Entwickler, lassen sich solche Aufgaben, flexibel mittels Richtlinien erledigen.

Microsoft Teams verwendet für die Rechteverwaltung die Office 365 Groups. Worauf man deswegen achten sollte, um die IT weiterhin sauber zu halten, wird im Folgenden beschrieben.

Für jedes neue Team in Microsoft Teams wird eine neue SharePoint Seite und eine neue Office 365 Gruppe angelegt. Daraus ergeben sich 2 Probleme:

• Wird ein neues Team angelegt für ein organisatorisch bereits aktives Team welches seine Arbeit in SharePoint bereits organisiert wird die SharePoint Landschaft schnell sehr unübersichtlich und unverständlich, da durch die Erstellung nun zwei gleichnamige SharePoint Seiten existieren.
• Eine Office 365 Group hat eine eigene E-Mail Inbox mit gleichnamiger Adresse. Falls ihr nun bereits einen E-Mail-Verteiler mit dem gleichen Namen habt, könnt ihr euch vorstellen, dass Mails nicht dort ankommen wo sie hinsollen, da die Gruppe leicht mit dem Verteiler verwechselt werden kann.

Was man dagegen machen kann:

Microsoft hat zur Lösung der oben genannten Probleme eine Möglichkeit geschaffen die Rechteverwaltung Tool-Übergreifend zu gestalten. Da Groups grundlegender für die Systemlandschaft sind als die einzelnen Services, empfiehlt es sich in erster Linie bestehenden Gruppen ein MS-Team zuzuweisen (Abbildung 2).

Falls ihr E-Mail Verteiler Listen verwendet und diese nicht umbenennen wollt, solltet ihr ein Präfix bei der Benennung des Teams verwenden (was sich auch auf die Group und SharePoint Seite auswirkt). Ein Beispiel könnte sein: „GRP_Teamname“. Auf diese Weise ist es auf einem Blick ersichtlich wohin die Mail geht.

Auch wenn jedes Microsoft Tool seine eigene, leicht zu verwendende Rechteverwaltung mitbringt, ist es auch möglich diese Tool-übergreifend zu gestalten. Es ist gut dies im Hinterkopf zu haben, bevor man ein neues Programm einführt. So erspart ihr euch später viel Frust.

Die SQLPass Deutschland hat dieses Jahr vom 26.-28.02. wieder die SQLKonferenz ausgerichtet. Stattgefunden hat die Veranstaltung im Darmstadium in Darmstadt. Ein Pre- und zwei Konferenztage, die vollgepackt waren mit interessanten und informativen Vorträgen rund um den SQL Server, Azure sowie BI- und Big Data - Themen.

Pass Deutschland e.V. ist die deutsche Microsoft Data Platform Community und richtet verschiedene Events rund um dieses Thema aus, unter anderem einmal im Jahr die SQLServer Konferenz. Der Verein ist nicht kommerziell und sieht es als sein Ziel, den Nutzern der Microsoft Data Plattform die notwendigen Mittel zu geben, um die taktischen und strategischen Ziele ihrer Organisation, unter Einsatz der Microsoft Data Plattform zu erreichen. (siehe www.sqlpass.de)

Der Vorstand des Vereins eröffnete dann auch die Konferenz mit einer entsprechenden Keynote. Unter anderem wurden einige der Aussteller und deren Tools vorgestellt. Besonders in Erinnerung geblieben ist mir die Firma DataCore-Software mit dem Tool MaxParallel. Damit wird die IO-Last eines Servers besser auf die zur Verfügung stehenden Kerne aufgeteilt und damit, wie der Name schon sagt, parallelisiert. Das ermöglicht eine Performanceverbesserung ohne jegliche Anpassung der eigenen Anwendung. 

Bei 58 Sessions und fast immer 6 gleichzeitig stattfindenden Vorträgen, fiel es mir bei manchen Slots schon wirklich schwer, mich zu entscheiden und fast immer waren die Sessions sehr informativ und interessant. Das alles hier aufzuführen würde wohl den Rahmen sprengen, deshalb beschränke ich mich auf eine kleine Auswahl, der für mich interessantesten Themen.

Aus dem Business Intelligent (BI) Bereich gab es einen Vortrag zum Power BI Report Server von Wolfgang Straßer. PowerBI.com ist ja bereits seit über 2 Jahren als cloudbasierter Dienst verfügbar, aber nicht jeder möchte seine Reports über die Cloud bereitstellen. Mit der Veröffentlichung des Power BI Report Server (PBIRS) im Juni 2017 wurde ein Teil der Power BI Funktionalität nun auch für das eigene Rechenzentrum und somit die eigenen Server verfügbar gemacht. Dies ermöglicht es, firmenintern Reports abrufbar zu machen. Der Funktionsumfang ist etwas eingeschränkt und die Nutzung muss entsprechend lizenziert sein. Man braucht entweder eine Power BI Premium Lizenz oder eine SQL Server Enterprise Edition mit Software Assurance. Mit dem geplanten Cloud- und on-premises Feature-Gleichstand von Microsoft kann man hier aber vermutlich noch einiges erwarten.

Ein weiterer Vortrag dieser Themenreihe war Power BI und IoT von Markus Raatz. Hier wurden die verschiedenen Streaming Möglichkeiten und deren Visualisierung vorgestellt. Leider geriet der Vortrag etwas kurz, da wir auf Grund eines Feueralarms das Gebäude verlassen mussten.

Aus Entwicklersicht war der Vortrag „SQL für alle Lebenslagen“ von Christoph Muthmann sehr spannend. Kurzweilig und mit vielen Beispielen aus dem alltäglichen Leben in der SQL Entwicklung, konnte man sich hier die ein oder andere Idee mitnehmen.

Einige interessante Vorträge gab es außerdem zu Datenbankanalyse und -optimierung. Besonders gut fand ich hier „Database tuning advisor vs. Database management views“ von Torsten Strauss und „Automatische Datenbankoptimierung … Funktioniert das wirklich?“ von Mark Aslan Kuschel.

Dabei ging es vorrangig darum, wie man die Indizierung der Datenbank optimal hält, also herausfindet, welche Indizes fehlen, nicht mehr gebraucht werden oder ineffizient sind. Ab SQL Server 2017 steht dafür eine automatische Datenbankoptimierung zur Verfügung. Genutzt werden dabei die DMV (Datenbank Management Views) und auf deren Grundlage wird über Neuanlage oder Löschen eines Index entschieden. Über die IndexUsage und MissingIndex Views kann man das natürlich auch manuell mit entsprechenden Abfragen ermitteln, aber blindlings ausführen würde ich das nicht. Oft gibt es hier doppelte oder sich überschneidende Vorschläge für neue Indizes und auch bei der Benutzung der Indizes werden nur Ausführungen seit dem letzten Neustart des Servers herangezogen. Ein deutlich besseres Ergebnis erhält man mit Hilfe des Database Tuning Advisors, auch wenn hier etwas mehr Vorbereitung nötig ist, bevor man ein Ergebnis erhält.

Seit SQL Server 2016 gibt es den QueryStore. Eine Live Abfragestatistik mit graphischer Oberfläche, über die ressourcenintensive Queries ausgewertet werden können, was die Analyse und auch Bearbeitung dieser Queries deutlich vereinfacht. Um dieses Feature auch Usern älterer Server Versionen verfügbar zu machen, wurde das Open Source Projekt OpenQueryStore ins Leben gerufen. Einer der Co-Kreatoren William Durkin hat in dieser Session das Design von OQS vorgestellt und in einigen Demos die Feature und auch Grenzen gezeigt. Wenn auch die graphische Oberfläche hier nicht interaktiv ist und einige Schritte per direktem SQL-Befehl gemacht werden müssen, ist das eine super Alternative und die Weiterentwicklung sicher noch nicht abgeschlossen.

Im Großen und Ganzen eine gelungene Veranstaltung, aus der ich sehr viel Input mitnehmen konnte und die SQLKonferenz im nächsten Jahr ist schon vorgemerkt.

Tame the Data Monster! Das Maskottchen der SQLPass gab es zur Erinnerung für alle am Ende der Konferenz noch zum Mitnehmen.

In einem aktuellen Projekt wurde im Zuge eines Hardwaretausches der SQL Server von 2008 auf 2014 migriert, wobei in diesem ersten Schritt keine funktionalen oder technischen Änderungen an den Datenbanken durchgeführt wurden. Da der SQL Server 2014 aber einige technische Verbesserungen mit sich bringt, soll nun überprüft werden, in wie weit diese für die bestehenden Datenbanken zur Verbesserung der Performance genutzt werden können. Die Ergebnisse meiner Recherche dazu möchte ich hier darstellen.

Wer kennt das nicht…?

• In eine DB strömen große Datenmengen aus verschiedenen Quellen
• Erwartet wird eine gute Leseperformance gekoppelt mit periodisch auftretenden Batch Inserts/Updates sowie eine niedrige Latenz
• Intensive Business Logik, die auf dem DB-Server ausgeführt werden muss

Und diese Liste kann man sicher noch um einiges erweitern. Der SQL Server 2014 verspricht aber mit der neuen InMemory-Technologie, an diesen Stellen helfen zu können.

Durch den Übertrag ganzer Tabellen oder auch nur von Teilen einer Tabelle in memoryoptimized tables und die Umwandlung von Transact-SQL Code in Natively compiled Stored Procedures soll sich die Performance deutlich verbessern (siehe Bild unten). Voraussetzung dafür ist aber auf jeden Fall genügend Arbeitsspeicher, da die Daten aus diese Tabellen im Arbeitsspeicher gehalten werden.

Wer wünscht sich das nicht… Benefits von In-Memory OLTP (Online Transaction Processing )

• Eliminierung von Konflikten
• Effizientes Einfügen der Data
• Geringere Wartezeiten
• Minimierung der Code Ausführungszeiten

Und auch hier ist die Liste, der von Microsoft versprochenen Verbesserung noch erweiterbar. Je nachdem wieviel Daten und auch Prozeduren übertragen werden, wird versprochen:

Um das auch bei unserem Projekt einsetzten zu können, habe ich mich durch einige Microsoft-Seiten gelesen (die Linksliste befindet sich unter diesem Beitrag) und versucht auf kompakte Weise einen für uns und wahrscheinlich auch für viele andere Projekte machbaren Weg zur Analyse und evtl. Umsetzung zu finden. Eine Vorab-Analyse ist sehr wichtig, da nicht alle Tabellen und Prozeduren für einen Übertrag geeignet sind. In manchen Projekten kann das Ergebnis dieser Analyse auch sein, dass ein Einsatz der InMemory-Technologie nicht ohne großen Umbauaufwand realisierbar ist. In diesem Fall sollte man immer abwägen, ob die angestrebte Performanceverbesserung den Aufwand tatsächlich gerechtfertigt oder es wert ist.

Um eine valide Aussage zur Verbesserung geben zu können, muss man den Vorzustand mit dem Nachzustand vergleichen können. Es ist also unerlässlich ein paar Daten zur Performance zu sammeln.

Für die Analyse der Datenstruktur und möglicher Bottlenecks, die durch inMemory verbessert werden könnten, stehen im SQL ManagementStudio Tools zur Verfügung. Zum einen ist das das ARM-Tool. Hier wird mit Hilfe des Management DataWarehouse eine Analyse der aktuellen Performance der Datenbank gemacht und als Ergebnis gibt es den Transaction Performance Analysis Report.

Das ARM-Tool gibt Vorschläge welche Tabellen und Proceduren für inMemory in Frage kommen, wie hoch die Performanceverbesserung wäre und welchen Migrationsaufwand man bei den Objekten hätte.

Außerdem gibt es noch den Memory Optimization Advisor und Native Compilation Advisor. Damit werden die zur Transformation ausgewählten Objekte auf eventuelle InMemory Unverträglichkeiten überprüft. Was unter anderem dazugehört, habe ich bereits in einem anderen Blogbeitrag beschrieben. (Link zu Blog: SQL Server InMemory).

Im folgenden Bild sind alle Schritte noch mal feiner gegliedert dargestellt.

Diese Herangehensweise wird auch so von Microsoft empfohlen und kann unter „Determining if a Table or Stored Procedure Should Be Ported to In-Memory OLTP“ siehe Linkliste, genauer nachgelesen werden. Dort ist auch sehr gut beschrieben, wie der Data Collector eingerichtet werden kann.

Weiterführende Links:

• Introduction to Memory-Optimized Tables: https://msdn.microsoft.com/en-us/library/dn511014(v=sql.120).aspx
• Requirements for Using Memory-Optimized Tables: https://msdn.microsoft.com/en-us/library/dn170449(v=sql.120).aspx
• Determining if a Table or Stored Procedure Should Be Ported to In-Memory OLTP: https://msdn.microsoft.com/en-us/library/dn205133(v=sql.120).aspx
• Memory Optimization Advisor: https://msdn.microsoft.com/en-us/library/dn284308(v=sql.120).aspx
• Natively Compiled Stored Procedures: https://msdn.microsoft.com/en-us/library/dn133184(v=sql.120).aspx
• Auch sehr interessant in dem Zusammenhang ist das folgende Dokument von Microsoft: http://download.microsoft.com/download/D/2/0/D20E1C5F-72EA-4505-9F26-FEF9550EFD44/InMemoryOLTP_WorkloadPatternsandMigrationConsiderations.docx