prog:oracle_ords_performance_tuning
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
prog:oracle_ords_performance_tuning [2017/09/06 21:16] – [Apache => Tomcat => ORDS Umgebung mod_jk optimieren] gpipperr | prog:oracle_ords_performance_tuning [2021/08/20 08:43] (aktuell) – [Quellen] gpipperr | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ===== Oracle APEX Webserver Stack mit Apache / Tomcat / ORDS / APEX Performance Überlegungen und Testes ==== | ||
+ | |||
+ | Installation mit entsprechenden Performance Anpassungen siehe: | ||
+ | * Linux => [[prog: | ||
+ | * Windows => | ||
+ | |||
+ | |||
+ | Vor dem Optimieren steht das Messen um vergleichbare Ergebnisse zu erzielen. | ||
+ | |||
+ | |||
+ | Als Basis für eine hochperformante APEX Umgebung benötigen wir eine möglichste schnelle " | ||
+ | |||
+ | Notwendige Messungen | ||
+ | * Timing der Statischen Elemente von APEX | ||
+ | * Timing einer vergleichbaren APEX Seite mit simplen SQL | ||
+ | * Timing einfacher ORDS Rest Service | ||
+ | |||
+ | |||
+ | Für das APEX und ORDS Rest Timing wird eine einfach Anwendung gestaltet um verschiedene Umgebung zu vergleichen. | ||
+ | |||
+ | Bzgl. Rest Data Service mit Oracle ORDS siehe [[prog: | ||
+ | |||
+ | Nach dem Vermesse dieser Testläufe wird die Umgebung optimiert bis zufriedenstellende Ergebnisse erzielt werden. | ||
+ | |||
+ | Ist dann alles in der Basis richtig eingestellt kann es an die Optimierung der eigentlichen Applikation gehen. Dort ist dann wohl der bedeutende Punkt das verwendete SQL, das ganz klassisch in der DB / Applikation optimiert werden kann. | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== Vorbereitung - Messen ==== | ||
+ | |||
+ | Um Messen wird das Apache JMeter Tool eingesetzt | ||
+ | |||
+ | |||
+ | * Apache JMeter herunterladen von http:// | ||
+ | * Entpacken z.B. nach C: | ||
+ | * Starten mit " | ||
+ | |||
+ | |||
+ | **<fc # | ||
+ | |||
+ | Falls ein 4K Monitor benützt wird, ist leider die Auflösung viel zu klein | ||
+ | |||
+ | Siehe auch => https:// | ||
+ | |||
+ | * Zoom in/out by using CTRL +/- | ||
+ | * jmeter.bat erweitern um (nach setlocal Zeile 51) <code java>set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.controlFont=Dialog-26 | ||
+ | set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.systemFont=Dialog-26 | ||
+ | set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.userFont=SansSerif-22 | ||
+ | set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.smallFont=SansSerif-22</ | ||
+ | |||
+ | |||
+ | Einen ersten Test anlegen => Siehe https:// | ||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | ====Timing der Statischen Elemente von APEX==== | ||
+ | |||
+ | Im ersten Testauf wird das Ausliefern der Statischen Elemente von APEX vermessen. Da hier kein Login notwendig ist ist der Test schnell aufgesetzt. | ||
+ | |||
+ | Der Test prüft die Leistung des HTTP Servers, in meine Fall einem Apache 2.4 HTTP. | ||
+ | |||
+ | Aus eine APEX App ermitteln wir uns als Testcase 10 typische Statische Elemente die mit einer Seite immer geladen werden wie: | ||
+ | |||
+ | <code > | ||
+ | |||
+ | https:// | ||
+ | |||
+ | 1 / | ||
+ | 2 / | ||
+ | 3 / | ||
+ | 4 / | ||
+ | 5 / | ||
+ | 6 / | ||
+ | |||
+ | </ | ||
+ | |||
+ | Diese binden wir in JMeter ein: | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
+ | Starten den Test und beobachten die Load auf der Maschine. | ||
+ | |||
+ | Nmon: | ||
+ | {{ : | ||
+ | |||
+ | |||
+ | |||
+ | Ergebniss im JMeter dann nach dem Lauf auswerten: | ||
+ | |||
+ | |||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
+ | Der URL Aufruf 2 chartBundle.min.js und 5 pd_static_data_en.json schwankt sehr stark. | ||
+ | |||
+ | Ein Test mit dem Oracle statischen < | ||
+ | | ||
+ | |||
+ | Nur was schließen wir nun aus diesem Ergebnis? | ||
+ | |||
+ | |||
+ | === CPU belegt vom ksoftirqd Prozess === | ||
+ | |||
+ | Was auffällt das optisch eine CPU nur mit Interrupts beschäftigt ist (in top " | ||
+ | |||
+ | => https:// | ||
+ | |||
+ | |||
+ | Das hat wohl mit dem Traffic auf der Netzwerkkarte zu tun, hier ist das Stichwort " | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Den gleichen Test werde ich nächste Woche auf einen weiteren System durchführen um hier Vergleichswerte zu haben. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== Apache mit einem Cache System unterstützen=== | ||
+ | |||
+ | siehe auch => https:// | ||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ | ==== Wie kann ich die Leistung des nun ORDS verbessern? ==== | ||
+ | |||
+ | |||
+ | === Neuest Release testen=== | ||
+ | |||
+ | Im ersten Schritt gleich auf das aktuellste Release umsteigen (3.0.11 September 2017, bzw. 2021 auf 20.4) um unnötige Bugs zu übergehen. | ||
+ | |||
+ | |||
+ | === Datenbank Pool Größe anpassen=== | ||
+ | |||
+ | Minimale und Maximale Pool Größe anpassen ( ORDS verwendet den Oracle Universal Connection Pool (UCP) ) | ||
+ | d.h. zu Beginn wird eine gewisse Anzahl an Connections aufgebaut, | ||
+ | |||
+ | |||
+ | Parameter in defaults.xml: | ||
+ | |||
+ | * jdbc.InitialLimit | ||
+ | * jdbc.MaxLimit | ||
+ | |||
+ | |||
+ | Bei diesen Parameter ist zu beachten, das viel hilft viel der Datenbank nicht hilft! D.h. sinnvolle produktive Werte liegen so bei 10/50 und sollten nicht zu groß gewählt werden! | ||
+ | |||
+ | |||
+ | === JVM Speicher ORDS Standalone optimieren === | ||
+ | |||
+ | Selten wird der ORDS wohl produktiv standalone eingesetzt werden, hier kann der Speicherbedarf ganz klassisch über " | ||
+ | |||
+ | |||
+ | === ORDS im Tomcat === | ||
+ | |||
+ | Tomcat optimieren => http:// | ||
+ | |||
+ | |||
+ | === Apache => Tomcat => ORDS Umgebung mod_jk optimieren === | ||
+ | |||
+ | |||
+ | **<fc # | ||
+ | <code apache> | ||
+ | ajp_get_endpoint:: | ||
+ | worker worker1 from 10 slots | ||
+ | </ | ||
+ | |||
+ | |||
+ | Mod_jk | ||
+ | |||
+ | * https:// | ||
+ | |||
+ | |||
+ | Parameter prüfen => https:// | ||
+ | |||
+ | |||
+ | |||
+ | Es ist zum empfehlen den Speicher für Tomcat wenigstens auf 2GB zu erhöhen! | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== Quellen ==== | ||
+ | |||
+ | |||
+ | |||
+ | Apache JMeter | ||
+ | * http:// | ||
+ | |||
+ | Web | ||
+ | * https:// | ||
+ | |||
+ | |||
+ | ==Oracle== | ||
+ | |||
+ | |||
+ | Foren: | ||
+ | * https:// | ||
+ | |||
+ | |||
+ | ORDS 3 Doku | ||
+ | * http:// | ||
+ | |||
+ | |||
+ | Apache Tomcat | ||
+ | |||
+ | * https:// | ||
prog/oracle_ords_performance_tuning.txt · Zuletzt geändert: 2021/08/20 08:43 von gpipperr