Am 31. Oktober wird Kirk Pepperdine - eine Autorität auf dem Gebiet des Java-Performance-Tunings - gemeinsam mit uns einen 4-tägigen Workshop abhalten. Fünf Xebia-interne Teilnehmer haben sich angemeldet und die restlichen sieben Plätze sind für externe Teilnehmer offen. Details zum Kurs finden Sie hier.Ich habe Kirk Pepperdine interviewt. Er ist CTO von javaperformancetuning.com und Herausgeber von TheServerSide. Kirk spricht über den Kurs, den er bei uns anbietet, seine Arbeit als Berater und wie er Leistungsprobleme vor Ort angeht. Wenn Sie also darüber nachdenken, den Kurs zu besuchen oder wenn Sie einfach nur nach Tipps und Erfahrungen zur Java-Performance suchen, ist dieses Interview genau das Richtige für Sie.
Jeroen: Können Sie uns ein wenig über sich und Ihre Arbeit erzählen?
Kirk: In erster Linie bin ich ein Entwickler und es macht mir Spaß, Anwendungen zu entwickeln und an verschiedenen Dingen herumzubasteln. Mein Streifzug durch die Leistungsoptimierung begann, als ich in einer Gruppe arbeitete, die Cray-Supercomputer verwendete. Es war schon etwas seltsam, dass ich morgens in Cray Assembler und nachmittags in Smalltalk programmieren konnte, wobei ich mittags ein wenig C einstreute. Jetzt helfe ich Teams bei der Lösung ihrer Leistungsprobleme. Ich editiere, schreibe und unterrichte auch, aber vor allem macht es mir Spaß, Code zu schreiben.
Mit der Leistungsoptimierung von Java habe ich Ende 97 begonnen. Jack Shirazi und ich wurden gebeten, die Leistung einer ziemlich großen Java-Anwendung zu optimieren. Ich glaube, es war das größte Java-Projekt in Europa zu dieser Zeit. Wie Sie sich vorstellen können, waren die Probleme nicht so einfach und es gab so gut wie keine Tools und keine Dokumentation. Ich begann, meinen eigenen Speicher-Profiler zu schreiben, da es zu Beginn keine kommerziellen Optionen gab. Diese Arbeit war die Inspiration für Jack, das Performance-Tuning-Buch zu schreiben. Er hat dann eine begleitende Website ins Leben gerufen und wir haben dann gemeinsam an der Erstellung von Materialien für die Website gearbeitet. All diese Arbeit hat nun dazu geführt, dass Sun auf uns beide aufmerksam geworden ist und wir nun beide Mitglieder des Java Champions Programms sind. Es ist eine überwältigende Erfahrung, mit all den wirklich talentierten Menschen in dieser Gruppe über die Zukunft von Java zu diskutieren.
Jeroen: Sie bieten bei uns am 31. Oktober, 1., 2. und 3. November die Schulung Speeding up Java applications a.k.a. JavaPerformance Tuning an. Worum geht es bei dieser Schulung und wer sollte daran teilnehmen?
Die Computerbranche ist eine ziemlich paradoxe Branche. Einerseits sind Computer gleichbedeutend mit Leistung und natürlich weiß jeder Programmierer, wie er den schnellsten Code schreiben kann. Andererseits stoße ich immer wieder auf Projekte, die unter verschiedenen Formen des gleichen Problems leiden. Als Jack und ich vor ein paar Jahren anfingen, diesen Kurs anzubieten, haben wir den Teilnehmern eine ziemlich routinemäßige Aufgabe gestellt. Dabei stellten wir fest, dass nicht eine einzige Person die Aufgabe des Tunings ohne Eingreifen bewältigen konnte. Es war nicht nur diese eine Gruppe, es war jede einzelne Gruppe, die wir trafen. Schließlich gelang es einer Person, das Problem zu lösen. Zu unserer großen Überraschung war er jedoch kein Entwickler! Derjenige, der das eigentliche Problem erkannt hatte, war ein Tester ohne viel Programmiererfahrung! Wir haben auch eine andere Übung, bei der nicht eine einzige Person in der Lage war, den wirklichen zugrunde liegenden Leistungsengpass zu identifizieren.
Es ist nicht so, dass eines dieser Probleme sehr schwierig wäre; es scheint nur so, dass viele Entwickler schlecht für den Umgang mit Leistungsproblemen ausgerüstet sind. Ich weiß nicht, warum das so ist, aber ich weiß, dass ein Entwickler, der den Kurs einmal absolviert hat, ein Leistungsproblem nie wieder mit denselben Augen sehen wird. Bei unserem letzten Angebot habe ich sogar einen Kommentar erhalten, der frei zitiert lautet: "Sie haben mir eine ganz neue Sichtweise auf dieses Problem gegeben". Es ist sehr befriedigend, diese Art von Kommentaren zu hören, denn das ist unser Ziel.
Jeroen: Ich werde den Kurs selbst verfolgen. Ich bin neugierig, wie er sein wird. Müssen die Teilnehmer einen Hintergrund als Java-Entwickler haben oder ist der Kurs auch für Tester mit Java-Grundkenntnissen geeignet?
Als wir den Kurs zum ersten Mal geschrieben haben, richteten wir uns ursprünglich an Entwickler. Da Entwickler gerne Code entwickeln, wurden viele der Übungen so gestaltet, dass sie für Entwickler interessant sind. Wir haben jedoch festgestellt, dass auch viele Tester mitmachen wollten. Einige von ihnen waren durchaus in der Lage, die Programmieraufgaben zu bewältigen, und wir haben denjenigen, die Schwierigkeiten hatten, ein wenig unter die Arme gegriffen, damit sie trotzdem von der beabsichtigten Lektion profitieren konnten. Wir haben auch spontan Übungen angepasst, um den besonderen Bedürfnissen einer Gruppe gerecht zu werden. Sie wissen nie, was auf Sie zukommt, wenn Sie eine dieser Sitzungen betreten. Deshalb haben wir darauf bestanden, dass jeder, der das Material präsentiert, über praktische Erfahrung im Bereich Performance-Tuning verfügt. Leistung ist ein dynamisches Thema. Die Lösungen für die Übungen sind nicht in Stein gemeißelt. Wir hatten schon Studenten, die Probleme auf überraschende Weise gelöst haben. Dies ist ein Aspekt des Kurses, der ihn unserer Meinung nach von Kursen unterscheidet, die "aus der Konserve" stammen, damit sie von einem Trainer gehalten werden können.
Jeroen: Ich finde, dass javaperformancetuning.com eine erstaunliche Leistungsressource ist. Können Sie uns etwas über die Seite und Ihr Unternehmen erzählen?
Wie ich bereits sagte, sollte javaperformancetuning.com eine Begleitwebsite zu Jacks Buch sein. Ich glaube, dass Tim O'Rielly ihn dazu ermutigt hat, sie zu starten. Kurz darauf kam ich an Bord, um einige Inhalte hinzuzufügen, aber das Nützlichste sind meiner Meinung nach die Tipps und die Toolberichte. Wir waren so beschäftigt, dass wir einige der Werkzeugberichte vernachlässigt haben, aber ich denke, das wird sich in den nächsten Monaten ändern. Ich habe einige interessante Tool-Berichte in der Pipeline.Wir bieten so ziemlich alles an, was mit Leistung zu tun hat. Dazu gehören White Paper, Benchmarking, Leistungsüberprüfungen und -optimierung sowie Architekturberatung.
Jeroen: Sie sind seit kurzem als Herausgeber von TheServerSide tätig. Was bedeutet das?
Meine Hauptaufgabe besteht darin, Inhalte zu beschaffen und sicherzustellen, dass sie für die Veröffentlichung auf der Website geeignet sind. In zweiter Linie bin ich an der Planung der TSS-Symposien beteiligt. Ich mache das nur auf einer Teilzeitbasis und die meiste Arbeit wird von einigen sehr engagierten und talentierten TechTarget-Mitarbeitern übernommen. Es ist nicht einfach, zu verstehen, was die Leute wollen, die Redner zu finden, die Abstracts zu organisieren und all die anderen Dinge. Es ist eine Menge Arbeit, aber die Belohnung ist es mehr als wert.
Jeroen: Können Sie uns eine typische, auffällige Kundensituation skizzieren, in der Sie als Leistungsüberprüfer oder Problemlöser auftreten?
Meine Güte, ein typischer Kunde... Ich bin mir nicht sicher, ob es einen typischen Kunden gibt, außer dass sie alle gestresst und möglicherweise am Ende ihrer Kräfte sind. Stress ist das Hauptproblem, und das muss vor allen anderen Dingen angegangen werden. Sie brauchen eine ruhige Umgebung, sonst ist es fast unmöglich, etwas zu erreichen. Das erste, wonach ich Ausschau halte, ist ein Druckentlastungsventil. Es wird in jeder Situation anders aussehen, aber Sie müssen es finden, auch wenn Sie dafür einige sehr unkonventionelle Schritte unternehmen müssen. Ich nenne das gerne strategische Hacks, also etwas, das manchmal so hässlich ist, dass es schwer zu sehen ist. Ich habe einmal einen Cronjob geschrieben, der alle paar Minuten die Datenbank abfragte, um die älteste Sitzung zu finden und sie dann einfach zu löschen. Sie werden mir zustimmen, dass dies ein ziemlich hässlicher Hack ist, aber der Effekt war dramatisch. Die Telefone hörten plötzlich auf zu klingeln und man spürte, wie eine Welle der Erleichterung durch den Raum schwappte.
Ich sollte auch den skeptischen Kunden erwähnen, den Kunden, der bereits 1 oder 2 oder vielleicht sogar 3 Berater hatte, um sich das Problem anzusehen. Tatsächlich habe ich gerade einem Partner geholfen, ein Angebot zu schreiben, das er bereits einem Kunden mit einem erheblichen Leistungsproblem vorgelegt hatte. Obwohl jeder der vorherigen Berater, die dieser Kunde bereits engagiert hatte, einen Erfolg verkündet hatte, bestand das Problem weiterhin. Ich bin mir nicht sicher, wie man einen Sieg verkünden kann, wenn man nicht in der Lage ist, das Problem zu charakterisieren, eine Lösung anzuwenden und dann die Wirkung erneut zu messen.
Sie können sich vorstellen, dass der Kunde uns gegenüber sehr skeptisch ist, da wir weder für ein Produktunternehmen arbeiten noch von ihm unterstützt werden. Was die meisten Kunden jedoch nicht wissen, ist, dass ein großes Produktunternehmen den nächstbesten Berater schickt, ohne auf dessen Fähigkeit zu achten, das Problem zu lösen. Es ist also nicht verwunderlich, dass wir auf skeptische Kunden stoßen, und es ist auch nicht verwunderlich, dass wir in der Lage sind, Probleme zu lösen, die die eigenen Berater der großen Produktunternehmen manchmal übersehen.
Jeroen: Was sind die typischsten und am häufigsten auftretenden Leistungsprobleme, auf die Sie in der Praxis stoßen?
Datenbankinteraktionen und Speicherverwaltung.
Jeroen: Was ist Ihre Lösung für diese Probleme? Wie erreichen Sie die Lösung?
Gute Frage und ich wünschte, ich wüsste eine echte Antwort darauf. Als Erstes müssen Sie die Ursache des Problems verstehen. Sobald Sie die Ursache erkannt haben, sind die Lösungen in der Regel selbsterklärend. Ich wurde zum Beispiel gebeten, eine Anwendung zu untersuchen, bei der eine Abfrage 40 Minuten dauerte. Ich unterhielt mich kurz mit der DBA und sie erstellte einen Abfrageplan, aus dem hervorging, dass ein vollständiger Tabellenscan ausgelöst wurde. Die DBA erkannte sofort, dass sie einen Index erstellen sollte, was natürlich zu Antwortzeiten von unter einer Sekunde führte. Und nein, das habe ich mir nicht ausgedacht. Sie fragen sich vielleicht, wie jemand etwas so Einfaches übersehen kann. Meine Antwort ist, dass es ziemlich häufig vorkommt, dass Menschen diese Art von Gelegenheiten aufgrund von Stress und der Komplexität der Umgebungen, in denen sie arbeiten, verpassen. Wenn Sie eine Reihe von Problemen haben, werden kleine Dinge wie eine 40-minütige Anfrage in all dem Lärm übersehen. Das kommt vor. Wir sind alle nur Menschen und können nur eine bestimmte Menge an Komplexität bewältigen, und noch weniger, wenn wir unter Stress stehen.
Jeroen: Welche Änderung haben Sie bei einem Projekt mit der größten Leistungssteigerung gesehen?
Nun, abgesehen von der Hinzufügung eines wichtigen Indexes sind die größten Verbesserungen alle auf grundlegende Änderungen der Architektur oder des Designs zurückzuführen. Ja, ich weiß, das bedeutet in der Regel eine komplette Neufassung. Wenn Sie jedoch die erste Version als Anforderungsdokument für die zweite Version verwenden, können Sie oft erstaunliche Einsparungen erzielen. Ich meine, wenn Sie sich die erste Implementierung genau ansehen, können Sie oft erkennen, was die wirklichen Anforderungen waren und diese Beobachtungen als Grundlage für die Anforderungen an die zweite Version verwenden. Ich sage gerne, dass weniger Code schneller läuft, und ich habe festgestellt, dass beim Umschreiben fast immer viel weniger Code übrig bleibt.
Jeroen: Sie haben einige Anti-Performance-Muster definiert. Wie lauten sie?
Es gibt so viele, aus denen Sie wählen können. Ich werde nur den größten und schlimmsten von allen erwähnen. Wenn Sie keine eindeutigen Beweise haben, die die Leistungsprobleme aufzeigen, bevor Sie etwas unternehmen. Und mit Beweisen meine ich etwas, das Sie Ihrer Mutter mit nach Hause geben können, damit sie sagt: "Oh ja, ich verstehe!". Wir nennen das: Raten Sie, messen Sie nicht, rufen Sie uns an. Es sollte keine Überraschung sein, dass die überarbeitete Lösung Measure, Don't Guess heißt. Meine Frau zieht es natürlich vor, dass Sie alle das Anti-Muster befolgen.
Jeroen: Oft sind der Datenbankzugriff und die O/R-Zuordnung für eine schlechte Leistung verantwortlich. Was ist Ihre Meinung dazu? Wie können wir das verhindern?
Ich zitiere gerne Doug Clarke, den Produktmanager für TopLink. Er wird oft gefragt, wie schnell TopLink ist. Die Antwort, die er gibt, lautet: "Wie schnell ist Ihr Fahrrad?". Diese Antwort mag ärgerlich sein, aber sie ist ziemlich genau richtig. O/R-Mapping-Tools verursachen zwar eine gewisse Verzögerung, aber im Großen und Ganzen ist das nichts im Vergleich zu einem guten alten Treffer im Netzwerk. Das Problem ist, dass es sich um eine wichtige und zugleich dumme Frage handelt. Es ist so gut wie unmöglich, aus einem Benchmark eine aussagekräftige Zahl herauszuholen. Die Antwortzeit wird ein gewichteter Durchschnitt der Antwortzeit aller Komponenten sein. Dazu gehören das Schema und viele dynamische Aspekte eines Systems. Das bedeutet, dass die Gewichtung bei jeder einzelnen Anwendung anders ausfällt. Die Frage, die Sie Doug und Gavin stellen, lautet: Wie hoch ist meine durchschnittliche Antwortzeit und Sie müssen übrigens alle Gewichtungen in der Gleichung erraten. Es gibt einfach viel zu viele Variablen, die man kontrollieren kann.
Gavin King hat einige interessante Benchmarking-Zahlen, die er nicht veröffentlichen will, weil sie seiner Meinung nach keinen Sinn ergeben und die Leute glauben würden, dass er sie erfunden hat. Es gibt einfach so viel Zeug, um ein aussagekräftiges Ergebnis zu erhalten, eines, das Ihnen hilft zu verstehen, was Sie erwarten sollten. Der jüngste Microsoft-Benchmark ist ein weiteres Beispiel für einen weiteren nutzlosen Benchmark. Sie behaupteten, dass ihre Implementierung der WebSphere-Referenzanwendung in .NET schneller läuft als in J2EE. Ich habe sie gefragt, warum, und sie hatten keine Antwort. Die Vermutung war, erinnern Sie sich an unser Mantra measure don't guess, die Vermutung war, dass die enge Kopplung zwischen .NET und Access für den marginalen Leistungsvorteil verantwortlich war. Wenn ich also diese Methode für den Datenbankzugriff verwende, bin ich fein raus; andernfalls wäre der J2EE-Stack wohl die bessere Wahl. Aber das ist nur eine Vermutung, denn der Benchmark hat die grundlegenden Fragen, die Architekten beantworten müssen, nicht beantwortet.
Benchmarking ist eine viel komplexere Aufgabe, als es klingt. Jeder, der glaubt, in einem Tag oder so Zahlen zu erhalten, hat dies noch nie versucht, wird falsche Zahlen melden oder braucht viel Glück.
Wie kann man eine schlechte Datenbankleistung verhindern? Fragen Sie Ihren DBA vor Ort. Ein guter DBA wird Wunder vollbringen, um sicherzustellen, dass Ihre Datenbank auf dem neuesten Stand ist und Sie solides SQL ausführen. Der nächste Schritt besteht darin, das O/R-Mapping-Tool dazu zu bringen, das gewünschte SQL zu erzeugen. Das kann schwierig sein.
Natürlich ist der beste Datenbankaufruf derjenige, den Sie nicht getätigt haben, und Sie können ihn vermeiden, wenn Sie Caching verwenden. Die Zwischenspeicherung ist dazu da, Ihre Anwendung vor der übermäßigen Nutzung einer langsameren zugrunde liegenden Technologie zu schützen. Daten in der Nähe sind besser als weit entfernte Daten, und ein Cache hält die Daten in der Nähe.
Jeroen: Welche Erfahrungen haben Sie mit neuen Technologien wie AJAX, SOA, ESB gemacht?
AJAX ist neu, und so sind die Berichte aus der Praxis gemischt. Das Problem mit AJAX ist, dass es die Idee, dass jemand schnell eine Verbindung nutzt, nicht so oft durchbricht. Das kann also nicht anders, als den Server stärker zu belasten. Mein Maßstab für die Leistung ist jedoch das Benutzererlebnis. Es ist mir egal, wie hart die Hardware arbeitet, dafür ist sie schließlich da. Die Auslastung der Hardware ist nicht so wichtig wie die Gewährleistung, dass der Benutzer in einer angemessenen Zeit bedient wird. Angemessen ist ein unscharfes Wort und ich verwende es absichtlich. Wenn AJAX die Benutzer so beschäftigen kann, dass sie keine "unangemessenen" Antwortzeiten bemerken, hat es seine Aufgabe erfüllt. Sie können mehr Hardware besorgen, aber die Benutzer zu beschäftigen ist in der Regel eine größere Herausforderung. Ich sollte noch hinzufügen, dass es Berichte gibt, wonach die Umstellung auf AJAX die Serverleistung verbessert hat. Wie gesagt, die Ergebnisse sind gemischt.
Ich bin überrascht, wie sehr SOA als Technologie gehypt wird, obwohl es in Wirklichkeit nur ein neues Etikett für ziemlich altes Zeug ist. Ich freue mich für SOA. Mit SOA lässt sich Ihr Code auf sehr nützliche Weise organisieren. Organisierter Code ist für die Leistungsoptimierung immer besser als unorganisierter Code. Außerdem können Sie sich mit einer einfachen Messung am Gateway auf das Wesentliche konzentrieren, nämlich die Antwortzeit.
ESB ist völlig abhängig von Ihrem Netzwerk, das wohl der langsamste Teil Ihrer Computerinfrastruktur ist. Die meisten ESBs verwenden XML, das wohl das fetteste Protokoll ist, das man verwenden kann. Wir haben es also mit einer Anwendung zu tun, die das fetteste Protokoll über die langsamste Infrastruktur verwendet, und Sie wollen über die Leistung sprechen. Es liegt auf der Hand, dass ein eng gekoppeltes Client/Server-Paar, das ein leichtgewichtiges Protokoll verwendet, eine ESB-Lösung in den Schatten stellen wird. Ich würde niemandem empfehlen, ESB zu verwenden, wenn die Leistung ein Problem darstellt. ESB bietet jedoch viele interessante architektonische und integrative Möglichkeiten, die die Sorge um schnelle Reaktionszeiten überlagern können.
Dies führt zu einer Reihe von Fragen, die wir in diesem Kurs behandeln. Uns geht es nicht um Leistung um jeden Preis, sondern wir sprechen darüber, wie Sie eine Leistung erreichen, die "gut genug" ist, und wie Sie vernünftige architektonische Entscheidungen treffen, die sowohl Ihren Leistungsanforderungen als auch Ihren geschäftlichen Bedürfnissen gerecht werden. Es liegt auf der Hand, dass die Systemintegration einige entscheidende Geschäftsvorteile bieten kann. Dennoch haben wir vielleicht nicht den Luxus, Anwendungen so umschreiben zu können, dass sie zusammenarbeiten können. Dies ist ein Punkt, an dem ESB einen enormen Vorteil bietet. Wenn es nicht schnell genug geht, werden wir als Branche natürlich herausfinden, wie wir es schneller machen können. Schließlich geht es in dieser Branche genau darum. Wenn das XML-Parsing zu schwer ist, dann kann man sich jetzt ein XML-Parsing-SPD besorgen, Problem gelöst!
Jeroen: Was ist ein "XML-Parsing-SPD" und wie beschleunigt es das XML-Parsing?
Ein XML-Parsing-Spezialgerät ist nur ein Stück Hardware, das speziell für das Parsen von XML entwickelt wurde. Es dient lediglich dazu, die Aufgabe des Parsens von XML von Ihrer CPU auf ein anderes Gerät zu verlagern, das theoretisch in der Lage sein sollte, diese Aufgabe effizienter zu erledigen. Ähnlich verhält es sich mit SSL. Sie können sich eine Hardware besorgen, die die gesamte Verschlüsselung übernimmt.
Dies führt zu einem weiteren interessanten Punkt. Es gibt inzwischen einige Unternehmen wie Azul Systems und das Niagara-Projekt von Sun MicroSystems, die Hardware verkaufen, die speziell darauf ausgerichtet ist, Java schneller laufen zu lassen.
Jeroen: Was meinen Sie genau mit "den Client an den Server koppeln", z.B. eng gekoppelt statt lose gekoppelt? oder wie co-located?
Ich meine damit die Kopplung auf Code- oder Datenstrukturebene, bei der Änderungen in der einen Anwendung Änderungen in der anderen erfordern. ESB kann auf Dienstebene gekoppelt sein, wenn Ihre Anwendung mit einem Kreditkartenservice interagieren muss. Die Abhängigkeit auf der Code-Ebene würde sich jedoch auf eine XML-Datei beschränken.
Jeroen: Wie stark wird die Leistung einer J2EE-Anwendung in der Regel durch die Verwendung von MVC-Frameworks wie Struts, Tapestry, MyFaces anstelle von einfachen Servlets beeinträchtigt?
Wenn Sie fragen, ob einfache Servlets immer besser sind als Anwendungen, die abstraktere Frameworks verwenden, dann gibt es darauf keine klare Antwort. Wir verwenden Frameworks, weil sie uns die Funktionen bieten, die wir brauchen. Jedes dieser Frameworks bringt einen Mehrwert mit sich. Die Verwendung dieser Frameworks ist jedoch nicht umsonst. Wenn Sie sich entscheiden, Ihr eigenes Framework zu entwickeln, können Ihre Entwickler Ihnen etwas geben, das besser funktioniert. Dieser Aspekt der Gleichung ist ein Glücksspiel. Was kein Glücksspiel ist, ist die Tatsache, dass Sie mehr Zeit benötigen, um die Funktionalität zu entwickeln, und dass Sie keine Mitarbeiter finden werden, die mit Ihrem selbst entwickelten Ansatz vertraut sind.
Im Allgemeinen überwiegen die wirtschaftlichen Vorteile der Verwendung dieser Frameworks die Bedenken hinsichtlich der Leistung, und meiner bescheidenen Meinung nach sollte das auch so sein. Richtig eingesetzt und in den richtigen Szenarien bietet jedes dieser Frameworks eine ausreichend gute Leistung. Wenn sie schlecht und in ungeeigneten Szenarien eingesetzt werden, sind alle Wetten verloren. Hier noch ein paar weitere Argumente für die Verwendung von Off-the-Self-Paketen: Gavin King hat schwache Referenzen aus Hibernate entfernt, was zu einer deutlichen Verbesserung der Leistung geführt hat. Wenn Sie Hibernate verwenden, sollten Sie durch ein Upgrade auf die neue Version eine deutliche Verbesserung der Leistung feststellen. Nebenbei bemerkt ist dies einer der Gründe, warum wir Komponenten und gutes Design über Performance-Bedenken stellen. Leistung um jeden Preis sollte keine Option sein.
Jeroen: Die Leistung wird in Projekten oft ignoriert, bis es in der Produktion zu kostspieligen Leistungsproblemen kommt. Haben Sie eine Erklärung dafür?
Ja, der Glaube, dass unser Code so schnell wie der Wind laufen wird und wenn nicht, können wir einfach mehr Hardware kaufen, um die Probleme zu überspielen. Aber im Ernst, das größte Problem ist die Zeit oder der vermeintliche Mangel daran. Selbst wenn der Zeitplan Zeit für Leistungstests vorsieht, ist dies die Aufgabe, die am Ende der Reihe steht und die am meisten zu kurz kommt. Es hat schließlich keinen Sinn, etwas zu optimieren, das nicht funktioniert.
Jeroen: Sollte es in einem Entwicklungsprozess explizite Leistungsaktivitäten geben? Wie würden Sie diese in einen Prozess einbauen?
Über dieses Thema sprechen wir in dem Kurs. In jeder Phase der Entwicklung gibt es nützliche Dinge, die Sie tun können, um sicherzustellen, dass Sie Ihre Leistungsziele erreichen werden. Zum Beispiel sollten Sie in der Anforderungsphase Leistungsziele sammeln und festlegen.
Jeroen: Ist das Hinzufügen neuer Hardware eine Lösung für Leistungs- und Skalierbarkeitsprobleme?
Es hängt wirklich von der Art Ihres Leistungsproblems ab und davon, wie Ihre Anwendung konzipiert, architektonisch gestaltet und implementiert wurde, und ich betone implementiert. Ich habe die Empfehlung ausgesprochen, dass die kostengünstigste Lösung darin besteht, mehr Hardware zu kaufen. Ich habe mich aber auch geweigert, diese Empfehlung auszusprechen, wenn ich wusste, dass dies überhaupt keinen Unterschied machen würde. Als erstes müssen Sie wissen, welche Ressourcenbeschränkung für das Leistungsproblem verantwortlich ist. Von da aus sollten Sie in der Lage sein, eine Analyse durchzuführen, um die beste Lösung zu finden. Das Mantra lautet: Messen Sie, raten Sie nicht.
Jeroen: Welche Performance-Tools befinden sich in Ihrem Werkzeugkasten und welche sind Ihre Favoriten? Was macht sie zu Ihren Favoriten?
Ich neige dazu, mich auf Tools zu verlassen, die manche als sehr primitiv bezeichnen würden. Wenn ich den Favoriten mit dem Nützlichsten gleichsetzen könnte, würde ich vmstat wählen. Sie werden vielleicht denken, dass es komisch ist, dass ein Tool, das kstat-Werte ausspuckt, beim Leistungstuning von Java so nützlich ist, aber Sie können damit ganze Klassen von Problemen in nur wenigen Minuten beseitigen. Wenn Sie nach einer Nadel im Heuhaufen suchen, ist es am besten, so viel Heu wie möglich im Voraus zu entfernen.
Jeroen: Sie meinen, Sie können Dinge wie zu viel Speicherverbrauch, Swapping, übermäßige Festplatten-E/A usw. schnell herausfinden?
Ganz genau. Wenn Sie sich alle Arten von Leistungsproblemen ansehen, müssen Sie zuerst diejenigen beseitigen, die auf die Hardware zurückzuführen sind. Wenn Ihre Hardware einwandfrei funktioniert, die Benutzer sich aber über die Reaktionszeiten beschweren, dann haben Sie es mit einem ganz anderen Leistungsproblem zu tun. Wenn ich es eilig habe, diese Nadel zu finden, dann möchte ich etwas, das das Heu sehr schnell beseitigt, und vmstat oder perfmon erledigen das für mich.
Jeroen: Ich denke, Ihr Mantra: Measure, Don't Guess, ist in der Tat entscheidend und wird meiner Erfahrung nach in der Praxis oft nicht gut angewandt. Wie wird dies in Ihrem Kurs behandelt?
Measure don't guess ist wie jedes andere Schlagwort. Es versucht, den Geist dessen zu erfassen, was in diesem Fall getan werden muss. Es sagt jedoch nur, was Sie tun sollten, ohne wirklich zu sagen, wie. Was der Kurs lehrt, ist das Was und Wie des Messens. Ich gebe Ihnen diese freundliche Warnung. Der Kurs spiegelt das wahre Leben wider. Sollten Sie sich entscheiden, das Mantra im Kurs zu ignorieren, werden Sie sich nur dumm vorkommen, während die Konsequenzen im Leben ziemlich ernst sein könnten.
Jeroen: Das war ein tolles Interview mit Ihnen, Kirk! Vielen Dank, dass Sie dieses Wissen und diese Erfahrungen mit uns teilen. Ich freue mich darauf, Ihren Kurs zu besuchen.
