Performance JPA

[JanHH]

Hallo,

vermutlich ziemlich allgemeine Frage, aber ich stell sie trotzdem mal.

wenn bei einer Webanwendung zwischen den submit-Klicks per JPA auf die Datenbank zugegriffen wird, wieviel kann man JPA da "zumuten", ohne das die Performance signifikant leidet und man mehrere Sekunden auf den nächsten Screen warten muss?

Also wenn man bspws. 50 oder 100 Datenbank-Zeilen aus diversen (durchaus Millionen Einträge langen) Tabellen holt, die Werte ändert und wieder schreibt, wobei die Zugriffe relativ simpel sein dürften weil die IDs der relevanten Zeilen bekannt sind.. geht das oder bei was für Auslastungen ist da so die Grenze? Wenn man mal davon ausgeht, das durchaus dreistellige Mengen an Usern auf die Anwendung zugreifen?

Mir ist auch klar dass das stark von dem verwendeten Servern abhängt.. aber wenn man mal von Postgresql, JBoss 6, und "durchschnittlichen Servern" ausgeht?

Gruß+Danke
Jan

 

[KSG9|sebastian]

Was soll man darauf Antworten?

Das hängt ausschließlich vom Design, den Servern, der Datenbank, optimierte Tabellen, Indizes und weiß Gott von was ab. Aber mit JPA hat das Thema primär eigentlich nix zu tun.

 

[nillehammer]

Das hängt ausschließlich vom Design, den Servern, der Datenbank, optimierte Tabellen, Indizes und weiß Gott von was ab. Aber mit JPA hat das Thema primär eigentlich nix zu tun.

Es gibt zwar die Tendenz, dass DB-Zugriffe per JPA langsamer sind, als plain JDBC. Das liegt aber eher an schlechten Mappings. Insofern stimme ich der o.a. Aussage zu.

 

[KSG9|sebastian]

Es gibt zwar die Tendenz, dass DB-Zugriffe per JPA langsamer sind, als plain JDBC. Das liegt aber eher an schlechten Mappings. Insofern stimme ich der o.a. Aussage zu.

Vollkommen richtig..aber das lässt sich im Vorfeld natürlich schwierig beurteilen. Wenn das Mapping sauber ist, die Indizes korrekt sind lässt sich schon mal sehr viel rausholen.

Während der Entwicklung und auch danach sollte man sich aber die teuren Querys anschauen und da nochmal optimieren. Im Vorfeld lässt sich das halt nicht tun, da gibt es eher so die Grundlagen zu beachten:

- Normalform ist schön, wenn aber jede Abfrage 30 Joins benötigt ist es weniger schön
- 1:1-Referenzen embedden
- korrekte Indizes
- Model/Mapping allgemein optimieren
...

Langsam wird es ohnehin auch sehr gerne beim Mapping auf Objekte. 150000 Datensätze zu lesen bringt normal noch keine wirklichen Probleme mit sich, daraus aber Objekte zu bauen und über die Leitung zu schicken ist schon eine ganz andere Nummer was Performance angeht...

 

[JanHH]

Danke für die Antworten. Naja gehen wir davon aus:

- es sind keine Joins notwendig
- fast alle Objekte lassen sich direkt per ID finden, es sind so gut wie kein Querys notwendig
- das objekt-Design ist ziemlich optimal

 

[KSG9|sebastian]

Dann hast du kein Performance-Problem im JPA-Layer
Wichtig ist dann noch, wie schon gesagt, senden der Objekte zum Client. Da musst du aufpassen das du 1) nicht viel zu viel unnötiges lädst und 2) nicht so wenig lädst das ständig lazy-loading zuschlägt

Vom Ansatz her mal ganz primitiv: Alles was direkt dargestelt werden soll per fetch-join, alles was über weitere Klicks erreichbar ist lazy.
Sobald das Benutzerverhalten/fachlicher Kontext klar ist kannst du da weiteroptimieren.

 

[JanHH]

Also auch dann keine Probleme zu erwarten wenn 50-100 Zeilen aus der Datenbank (aus diversen, verschiedenen Tabellen) gelesen, geändert und wieder geschrieben werden sollen?

 

[Ullenboom]

Bei so wenig Daten lacht Java, JPA, der JDBC-Treiber, und die Datenbank dich aus, dass du nicht mehr Arbeit gibst. Der JPA-Layer kostet dich ein paar Millisekunden, doch die fallen bei deinem Szenario wohl nicht ins Gewicht.

 

[nillehammer]

Danke für die Antworten. Naja gehen wir davon aus:

- es sind keine Joins notwendig
- fast alle Objekte lassen sich direkt per ID finden, es sind so gut wie kein Querys notwendig
- das objekt-Design ist ziemlich optimal

Zumindest Punkt 1 wage ich zu bezweifeln. Wenn die Klassen untereinander Beziehungen haben, wird es zumindest dafür JOINs geben. Auch wenn Du sie nicht selbst implementierst, macht JPA das unter der Haube. Das verändert aber die sonst gemachten Aussagen nicht wesentlich.

 

[JanHH]

Ne, haben weitgehend keine Beziehungen. Lauter einsame Entities.. :-(

Kollege meinte noch, 100 Millionen Zeilen lange Tabellen wären zwar an sich kein Problem, aber man muss schon ein bisschen optimieren bei der Konfiguration der Datenbank. Partitionierte Tabellen und so. Klang plausibel. Also Datenbank geschickt anlegen, dann gehts.

 

[Bleiglanz]

Gab's da nicht mal den Spruch Premature optimization is the root of all evil?

Erst mal mach es RICHTIG, optimieren kann man erst wenn die Anwendung läuft

 

[bronks]

Gab's da nicht mal den Spruch Premature optimization is the root of all evil?

Erst mal mach es RICHTIG, optimieren kann man erst wenn die Anwendung läuft

Oh ja! Wie zu alten Zeiten!

 

[JanHH]

Ja, das ist schon klar..

 

[Sanix]

Du musst vor allem auf lazy geladene Relationen achten. Teilweise macht JPA ein extra select dafür (je nach Provider). Das kann sich ziemlich schnell summieren. Aber das kann man, wie bereits erwähnt, am Schluss noch mehr optimieren. Einfach SQL ausgeben lassen.

 

[fastjack]

Bevor Du loslegst mach doch einfach mal einen Test. Kleiner Prototyp der Anwednung, generierte DB mit den Millionen Einträgen und dann Feuer frei mit JPA und JBoss (vom Client).