Ich schreibe eine Java EE 6-Webanwendung und bemerke einen erheblichen Leistungseinfluss bei der Verwendung eines injizierten Objekts im Gegensatz zum direkten Erstellen und Verwenden des Objekts. Der Overhead scheint in der Größenordnung von 50 - 60 ms pro Methodenaufruf zu liegen.
Zum Beispiel dauert die Verwendung nicht injizierter 150-Methodenaufrufe ungefähr 500 ms, während die Verwendung der Methodenaufrufe mit injizierten Objekten 150.000 - 13.000 ms benötigt. Eine Größenordnung Unterschied und dann einige.
Ist das üblich?
Ich laufe auf JBoss AS 7.1.1 final, das Weld verwendet, um mit CDI umzugehen.
Das injizierte Objekt wird als Singleton-Bean definiert (über die Annotation javax.ejb.Singleton). Könnte dies einen Teil des Problems verursachen? Oder ist es nur der Weld-Proxy, der die Verlangsamung verursacht?
Nach einiger Hilfe vom ausgezeichneten Weld-Forum habe ich folgendes entdeckt:
Singleton-Session-Beans sind standardmäßig transaktional (Abschnitt 13.3.7 der EJB 3.1-Spezifikation) und erfordern den Erwerb einer Exklusivlizenz Sperre für jeden Aufruf der Geschäftsmethode (Abschnitte 4.8.5.4 und 4.8.5.5). Im Gegensatz dazu ist javax.inject.Singleton nicht transaktional und unterstützt keine durch Container gesteuerte Nebenläufigkeit (die Hauptkomponente) Konsequenz ist, dass kein Sperrschema durch die Container).
Wenn Sie Ihre Singleton-Session-Bean mit kommentieren @TransactionAttribute (NOT_SUPPORTED) und @Lock (READ), sollten Sie sehen deutlich bessere Leistung, obwohl es immer noch einige geben kann Overhead. Wenn Sie keine EJB-Funktionen benötigen, bleiben Sie dabei @ApplicationScoped (javax.inject.Singleton ist nicht von CDI definiert, und seine Semantik unterliegt daher nicht dieser Spezifikation).
Leider war die Leistung auch nach der Annotation meines EJB-Singletons mit @TransactionAttribute (NOT_SUPPORTED) und @Lock (READ) immer noch sehr schlecht (siehe Timings vom ursprünglichen Beitrag).
Die Take-Home-Nachricht enthält also keine EJB Singleton-Session-Beans, es sei denn, Sie müssen unbedingt den Leistungs-Overhead berücksichtigen, der wahrscheinlich auftritt. Für Methoden, die selten aufgerufen werden, kann es vernachlässigbar sein, aber wie in unserem Fall akkumulieren sich kleine Gemeinkosten schnell, wenn es sich um eine stark genutzte Methode handelt.
Wir brauchten die EJB-Funktionen nicht und beim Umschalten auf ApplicationScoped sah man Verbesserungen der Leistung der spezifischen Methode, die durch die injizierte Bean aufgerufen wurde, in der Größenordnung.
Tags und Links java jboss7.x java-ee-6 cdi jboss-weld