Web-Notizen von Stefan Hinker SPARC, Solaris, Performance und der ganze Rest

Oder vielmehr - Lange lebt Solaris

Solaris 9 wurde im Mai 2002 angekuendigt, das ist jetzt sieben (7) Jahre her.  Am 28.  April war das offizielle "End of Life Announcement", am 30.10.2009 ist also "Last Ship Date".  Damit ist Solaris 9 nach 7 Jahren in die erste Supportphase eingetreten.  Wenn es am 30.10.2014 den Status "End of Supported Life" bekommt, wird es 12 Jahre am Markt gewesen sein.  Die genauen Daten zu den einzelnen Phasen findet man hier, eine Uebersicht ueber den "Life Cycle" aller Solaris-Versionen hier.

Solaris 8 gibt es seit Februar 2000, nach etwas ueber 12 Jahren am Markt wird es am 31.3.2012 EOSL sein.  Die Details zu diesem Release gibt es hier.

Solaris 10 war am 5.3.2005 erstmalig verfuegbar.  Der frueheste Zeitpunkt fuer eine Vorankuendigung ist 4 1/2 Jahre spaeter, als fruehestens am 5.9.2009.  Dann waeren es noch 6 1/2 Jahre bis zum EOSL, also mindestens bis zum 5.3.2016.  Das waeren dann insgesamt 11 Jahre, die Solaris 10 am Markt gewesen sein wird - mindestens.  Denn die Vorankuendigung muss ja nicht zum fruehestmoeglichen Zeitpunkt kommen...

Solaris 8 - 12 Jahre
Solaris 9 - 12 Jahre
Solaris 10 - mindestens 11 Jahre

Das macht sonst keiner.  Wir mit Solaris schon - Solaris macht es uns moeglich.

(Wer einen Vergleich sehen will, kann z.B. auf Seite 6 einer Praesentation von Volker Wetter zum Thema SAP und Solaris nachsehen )

Seit gestern gibt es auf developers.sun.com eine eigene Seite fuer CMT Systeme.  Dort sind all die Dokumente verzeichnet, die man bisher mehr oder weniger muehevoll zusammensuchen musste.  Ein wenig Marketing ist sicher auch dabei, aber der Gedanke von "One Stop Shopping" wurde schoen umgesetzt.

Nebenbei kann ich nicht umhin zu bemerken, dass auch dieser mein Blog dort verzeichnet ist --- das ist schon ein wenig schmeichelhaft

Funktioniert hat es natuerlich bisher auch schon.  Aber fuer alle diejenigen, die ein offizielles Supportstatement brauchen, ist dieses nun verfuegbar.  MySQL ist in einer LDom supported.

Anfang der Woche war ich bei einem Kunden, um mal wieder das unmoegliche Moeglich zu machen und die Antwortzeit einer Transaktion eines Applicationservers zu beschleunigen.  Es ging um eine Java-Anwendung auf einer T5140, und normalerweise ist hier zwar durch GC-Optimierung der JVM der Durchsatz noch zu steigern, an den Antwortzeiten einer einzelnen Transaktion ist jedoch selten etwas zu gewinnen.  Das liegt einfach in der Natur der Dinge...  Anders hier:

Der erste Ansatz war natuerlich, erst einmal generisch sinnvolle Parameter zum Aufruf der JVM zu verwenden, wie sie sich z.B. erst kuerzlich wieder bei einem grossen Benchmark bewaehrt haben.  Was mich ja immer wieder wundert, ist warum auch nach ueber 10 Jahren Java immer noch "-server" so oft fehlt... Erstaunlicherweise war das Ergebnis jedoch schlechter als vorher!  Erst ein genauerer Blick auf die sonstigen, oft ja sehr vielfaeltigen Optionen auf der Kommandozeile der JVM half weiter:  Dort war ein "-Djava.compiler=NONE" zu finden.  Das Ersetzen von "NONE" durch "jitc" wirkte die Sorte Wunder, die es sonst kaum noch gibt:  Die Antwortzeiten halbierten sich, der Durchsatz liess sich vom bisherigen Maximum von 35 TPS auf 130 TPS steigern.  Wenn das nicht Spass macht!  Fast schade, dass so etwas nicht oefter vorkommt