EJB 3.2 Leistungseinbußen

Question

Ich aktualisiere derzeit ein EJB-Projekt von Version 2.0 auf Version 3.2 (alle Stateful). Die Geschäftslogik bleibt die gleiche, die einzige Sache, die sich ändert, ist der EJB-Teil (Ersetzen von Deskriptor-Dateien durch Anmerkungen, Verwenden von Injektionspunkten anstelle von traditionellen Suchen usw.). Aus der Sicht der Anfrage Verarbeitung scheint alles gut zu funktionieren, das Problem ist mit der Leistung. Bei einem angeschlossenen Client dauert jede Anfrage etwa 300 ms. Wenn ich einen zweiten Client hinzufüge, springt die durchschnittliche Zeit auf 700 ms. Bei einem dritten Client überschreitet der Durchschnitt 1 Sekunde und so weiter. Mit der EJB 2.0-Version erhöht sich die Verarbeitungszeit leicht (50 ~ 100ms), selbst bei mehr Clients, aber keine Sorge.

Die Verschlechterung ist ziemlich offensichtlich, und ich kann einfach nicht den Grund herausfinden.

Ich habe mit EJB Timeouts, Transaktionstypen, etc. gespielt, aber ohne Glück. Ich habe auch versucht, den Server (über JMC) zu profilieren, konnte aber nichts Verdächtiges finden.

Es ist, als ob alle Anfragen nacheinander und niemals gleichzeitig bearbeitet werden.

Kann jemand Hinweise zu möglichen Ursachen geben? Gibt es irgendeine Konfiguration, die ich vermisse?

Hinweis: Das Problem tritt sowohl bei WebSphere 9 und GlassFish 4.1.1, so ist es eindeutig ein Problem der Anwendung.

EDIT # 1

Nach der Anwendung des Protokoll überprüft, kann ich bestätigen, dass die Anforderungen der Reihe nach verarbeitet werden, keine Gleichzeitigkeit.

Michaels Vorschlag folgend, sah ich ein Thread-Dump und in einem Augenblick gegeben, es gab:

• 27 RUNNABLE
• 18 TIMED_WAITING (auf Objekt-Monitor)
• 6 TIMED_WAITING (Parkplatz)
• 16 TIMED_WAITING (Schlafen)
• 23 WAITING (auf Objektmonitor)
• 40 WAITING (Parken)

Keine Anzeichen für blockierte Gewinde.

Irgendeine Idee?

Answer 1

Wie testen Sie das?

Das klingt für mich wie mehrere Clients die gleiche statusbehaftete Session-Bean-Instanz bekommen.

Der Container serialisiert Aufrufe an dieselbe SFSB-Instanz. Es sollte das tun und wenn es vorher nicht geschehen ist, dann hatten Sie vielleicht einen plattformabhängigen Deployment Deskriptor, der dieses Verhalten deaktiviert hat.

Wenn Sie jedoch ein Testframework verwenden und alle seine Clients die gleiche Sitzung erhalten, dann sieht dies auch so aus, als ob Sie ein Problem haben.

§4.3.13 "Serialisierung Session Bean Methoden" der EJB-Spezifikation sagt:

Der Behälter Anrufe an jede Stateful und Stateless Session Bean-Instanz serialisiert. Die meisten Container unterstützen viele Instanzen einer Session-Bean , die gleichzeitig ausgeführt wird. jede Instanz sieht jedoch nur eine serialisierte Sequenz von Methodenaufrufen. Daher muss eine statusbehaftete oder Stateless Session-Bean nicht als Reentrant codiert werden.

Wenn Sie eine einzelne SFSB-Instanz für alle Clients freigeben, kann es sinnvoll sein, sie von @Stateful zu @Singleton zu ändern. Singleton EJBs geben explizite Reentrancy-Steuerungen über die @ConcurrencyManagement und @Lock Annotationen. Wenn Sie mit der Gewindesicherheit Ihres EJB völlig zufrieden sind, können Sie Ihre Bean-Markierung markieren:

@Singleton 
@ConcurrencyManagement(ConcurrencyManagementType.BEAN) 
public class MyStatefulSessionBeanMasqueradingAsASingleton { 
    ... 
}