Ich erwäge, einen Cache zu verwenden, entweder JBoss Cache oder Ehcache. Nachdem ich mir beide APIs angeschaut habe, habe ich die Intuition, dass JBoss wahrscheinlich ein bisschen mehr Speicher effizienter ist als Ehcache, da es rohe Objekte in den Cache legen kann, während Ehcache die Daten in ein Element Objekt einbinden muss .
Ich richte eine schnelle Bank ein, die wiederholt Schlüssel-, Wert-Tupel in den Cache einfügt. Die Schlüssel- und Werteklassen sind sehr einfach:
Taste:
%Vor%Wert:
%Vor% Beim Einfügen von 100000 Objekten das Ergebnis im Speicher war, was ich erwartet hatte, verwendet Ehcache 13396 Bytes, um die Objekte zu speichern, während JBoss 5712 Bytes für die gleiche Operation verwendet (das ist gut, da der gleiche Test mit ConcurrentHashMap 5680 Bytes verwendet) ).
Aber als ich mir die Ausführungszeiten ansah, hatte ich eine sehr schlimme Überraschung: Ich brauchte Ehcache 300 Millisekunden, um meinen Test durchzuführen, während es bei JBossCache 44 Sekunden dauerte, um das Gleiche zu tun. Ich bin mir ziemlich sicher, dass in meiner JBoss-Konfiguration etwas faul ist, was diesen Unterschied erklärt.
Ehcache wird programmgesteuert wie folgt initialisiert:
%Vor%Der JBoss-Cache wird mithilfe von Spring mit der folgenden Bean-Konfiguration erstellt:
%Vor% und die folgende jbossCacheConf.xml -Datei:
Der Vollständigkeit halber ist der Ehcache-Test:
%Vor%Während der JBoss ist:
%Vor%Irgendwas stimmt nicht in meinem Setup / Benchmark?
Ich bin zu infinispan gewechselt und habe dann keine merkwürdigen Leistungsprobleme.
Achten Sie auf die standardmäßige JBossCache-Konfiguration. Es könnte möglich sein, dass JBossCache standardmäßig versucht, Daten auf einem Slave-Knoten zu finden und zu replizieren.
Tags und Links java performance ehcache jboss-cache