You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Mark Struberg <st...@yahoo.de> on 2014/10/21 11:37:21 UTC
CDI container performance
Hi!
Yesterday I wrote a small micro benchmark to test the performance of some CDI containers. The outcome was pretty stunning - but best if you run it yourself:
https://github.com/struberg/cdi-performance
$> git clone https://github.com/struberg/cdi-performance.git
$> cd cdi-performance
Just look for the output: ALL THE STUFF TOOK: xxx ms
The default profile runs with owb-1.2.6 which is currently used in TomEE-1.7.1:
$> mvn clean install
If you have OWB trunk installed you can also try the performance of OWB-1.5.0-SNAPSHOT:
$> mvn clean install -POWB15
There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
$> mvn clean install -POWB11 -Dowb.version=1.1.8
The numbers of the Reference Implementation (RI: Weld) can be tested via
$> mvn clean install -PWeld
but take your time and let it run - no it doesn't hang ;)
The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the latest RI version.
Feel free to debug into it if you don't believe our sheer crazy performance!
As a result of this performance I was able to serve FAT applications with BIG pages (huge JSF datatables) within under 150ms where other EE containers took 2 seconds++...
LieGrue,
strub
Re: CDI container performance
Posted by Alex Soto <as...@gmail.com>.
Yeah! I already read yesterday when I see you publish it on Twitter. Quite
impressive how an open source container can overpass another open source
container although that container has a company behind it.
Of course as you mention this is only a basic test, but it would be awesome
to test for example events, interceptors, decorators, and so on.
Anyway really good work :)
2014-10-21 11:37 GMT+02:00 Mark Struberg <st...@yahoo.de>:
> Hi!
>
> Yesterday I wrote a small micro benchmark to test the performance of some
> CDI containers. The outcome was pretty stunning - but best if you run it
> yourself:
>
> https://github.com/struberg/cdi-performance
>
>
>
> $> git clone https://github.com/struberg/cdi-performance.git
> $> cd cdi-performance
>
> Just look for the output: ALL THE STUFF TOOK: xxx ms
>
>
>
>
> The default profile runs with owb-1.2.6 which is currently used in
> TomEE-1.7.1:
>
> $> mvn clean install
>
> If you have OWB trunk installed you can also try the performance of
> OWB-1.5.0-SNAPSHOT:
> $> mvn clean install -POWB15
>
>
> There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
> $> mvn clean install -POWB11 -Dowb.version=1.1.8
>
>
> The numbers of the Reference Implementation (RI: Weld) can be tested via
> $> mvn clean install -PWeld
>
> but take your time and let it run - no it doesn't hang ;)
>
>
>
> The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and
> similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the
> latest RI version.
>
>
> Feel free to debug into it if you don't believe our sheer crazy
> performance!
>
> As a result of this performance I was able to serve FAT applications with
> BIG pages (huge JSF datatables) within under 150ms where other EE
> containers took 2 seconds++...
>
>
>
> LieGrue,
> strub
>
--
+----------------------------------------------------------+
Alex Soto Bueno - Computer Engineer
www.lordofthejars.com
+----------------------------------------------------------+
Re: CDI container performance
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Tue, Oct 21, 2014 at 6:00 AM, Romain Manni-Bucau <
rmannibucau@tomitribe.com> wrote:
> > OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
> > 1.7.x releases?
> >
>
> It is in TomEE 2
Nice to hear, thanks Romain! :)
Re: CDI container performance
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Tue, Oct 21, 2014 at 6:00 AM, Romain Manni-Bucau <
rmannibucau@tomitribe.com> wrote:
> > OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
> > 1.7.x releases?
> >
>
> It is in TomEE 2
Nice to hear, thanks Romain! :)
Re: CDI container performance
Posted by Romain Manni-Bucau <rm...@tomitribe.com>.
2014-10-21 11:57 GMT+02:00 Howard W. Smith, Jr. <sm...@gmail.com>:
> Wow, very impressive. I'm glad I'm using TomEE+ 1.7.1 (for now) and looking
> forward to TomEE+ 2.x.
>
> Questions below,
>
>
>
> - OWB-1.5.0: 13 ms (no this is NOT a hoax, it's due to our proxy caching
> [1]...)
>
> All with Java8.
>
> Currently trying to run it on other boxes to rule out some misconfiguration
>
> [1] For @ApplicationScoped beans our proxies resolve the contextual
> instance only once. Thus you get the benefits of a Proxy (serializability,
> interceptors, decorators, cycle prevention, shield against scope
> differences) for the costs of (almost) native invocation (Creating
> 'underTest' via new instead of the CDI bean will run the test in 8ms).
>
>
> OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
> 1.7.x releases?
>
It is in TomEE 2
> @ApplicationScoped? interesting, I can remember you sending a
> recommendation (to me via this list) about caching data in my app, and I
> did that in my (CDI) @ApplicationScoped bean. Thanks Mark! :)
>
>
>
> On Tue, Oct 21, 2014 at 5:37 AM, Mark Struberg <st...@yahoo.de> wrote:
>
>> Hi!
>>
>> Yesterday I wrote a small micro benchmark to test the performance of some
>> CDI containers. The outcome was pretty stunning - but best if you run it
>> yourself:
>>
>> https://github.com/struberg/cdi-performance
>>
>>
>>
>> $> git clone https://github.com/struberg/cdi-performance.git
>> $> cd cdi-performance
>>
>> Just look for the output: ALL THE STUFF TOOK: xxx ms
>>
>>
>>
>>
>> The default profile runs with owb-1.2.6 which is currently used in
>> TomEE-1.7.1:
>>
>> $> mvn clean install
>>
>> If you have OWB trunk installed you can also try the performance of
>> OWB-1.5.0-SNAPSHOT:
>> $> mvn clean install -POWB15
>>
>>
>> There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
>> $> mvn clean install -POWB11 -Dowb.version=1.1.8
>>
>>
>> The numbers of the Reference Implementation (RI: Weld) can be tested via
>> $> mvn clean install -PWeld
>>
>> but take your time and let it run - no it doesn't hang ;)
>>
>>
>>
>> The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and
>> similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the
>> latest RI version.
>>
>>
>> Feel free to debug into it if you don't believe our sheer crazy
>> performance!
>>
>> As a result of this performance I was able to serve FAT applications with
>> BIG pages (huge JSF datatables) within under 150ms where other EE
>> containers took 2 seconds++...
>>
>>
>>
>> LieGrue,
>> strub
>>
Re: CDI container performance
Posted by Romain Manni-Bucau <rm...@tomitribe.com>.
2014-10-21 11:57 GMT+02:00 Howard W. Smith, Jr. <sm...@gmail.com>:
> Wow, very impressive. I'm glad I'm using TomEE+ 1.7.1 (for now) and looking
> forward to TomEE+ 2.x.
>
> Questions below,
>
>
>
> - OWB-1.5.0: 13 ms (no this is NOT a hoax, it's due to our proxy caching
> [1]...)
>
> All with Java8.
>
> Currently trying to run it on other boxes to rule out some misconfiguration
>
> [1] For @ApplicationScoped beans our proxies resolve the contextual
> instance only once. Thus you get the benefits of a Proxy (serializability,
> interceptors, decorators, cycle prevention, shield against scope
> differences) for the costs of (almost) native invocation (Creating
> 'underTest' via new instead of the CDI bean will run the test in 8ms).
>
>
> OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
> 1.7.x releases?
>
It is in TomEE 2
> @ApplicationScoped? interesting, I can remember you sending a
> recommendation (to me via this list) about caching data in my app, and I
> did that in my (CDI) @ApplicationScoped bean. Thanks Mark! :)
>
>
>
> On Tue, Oct 21, 2014 at 5:37 AM, Mark Struberg <st...@yahoo.de> wrote:
>
>> Hi!
>>
>> Yesterday I wrote a small micro benchmark to test the performance of some
>> CDI containers. The outcome was pretty stunning - but best if you run it
>> yourself:
>>
>> https://github.com/struberg/cdi-performance
>>
>>
>>
>> $> git clone https://github.com/struberg/cdi-performance.git
>> $> cd cdi-performance
>>
>> Just look for the output: ALL THE STUFF TOOK: xxx ms
>>
>>
>>
>>
>> The default profile runs with owb-1.2.6 which is currently used in
>> TomEE-1.7.1:
>>
>> $> mvn clean install
>>
>> If you have OWB trunk installed you can also try the performance of
>> OWB-1.5.0-SNAPSHOT:
>> $> mvn clean install -POWB15
>>
>>
>> There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
>> $> mvn clean install -POWB11 -Dowb.version=1.1.8
>>
>>
>> The numbers of the Reference Implementation (RI: Weld) can be tested via
>> $> mvn clean install -PWeld
>>
>> but take your time and let it run - no it doesn't hang ;)
>>
>>
>>
>> The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and
>> similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the
>> latest RI version.
>>
>>
>> Feel free to debug into it if you don't believe our sheer crazy
>> performance!
>>
>> As a result of this performance I was able to serve FAT applications with
>> BIG pages (huge JSF datatables) within under 150ms where other EE
>> containers took 2 seconds++...
>>
>>
>>
>> LieGrue,
>> strub
>>
Re: CDI container performance
Posted by Romain Manni-Bucau <rm...@tomitribe.com>.
2014-10-21 11:57 GMT+02:00 Howard W. Smith, Jr. <sm...@gmail.com>:
> Wow, very impressive. I'm glad I'm using TomEE+ 1.7.1 (for now) and looking
> forward to TomEE+ 2.x.
>
> Questions below,
>
>
>
> - OWB-1.5.0: 13 ms (no this is NOT a hoax, it's due to our proxy caching
> [1]...)
>
> All with Java8.
>
> Currently trying to run it on other boxes to rule out some misconfiguration
>
> [1] For @ApplicationScoped beans our proxies resolve the contextual
> instance only once. Thus you get the benefits of a Proxy (serializability,
> interceptors, decorators, cycle prevention, shield against scope
> differences) for the costs of (almost) native invocation (Creating
> 'underTest' via new instead of the CDI bean will run the test in 8ms).
>
>
> OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
> 1.7.x releases?
>
It is in TomEE 2
> @ApplicationScoped? interesting, I can remember you sending a
> recommendation (to me via this list) about caching data in my app, and I
> did that in my (CDI) @ApplicationScoped bean. Thanks Mark! :)
>
>
>
> On Tue, Oct 21, 2014 at 5:37 AM, Mark Struberg <st...@yahoo.de> wrote:
>
>> Hi!
>>
>> Yesterday I wrote a small micro benchmark to test the performance of some
>> CDI containers. The outcome was pretty stunning - but best if you run it
>> yourself:
>>
>> https://github.com/struberg/cdi-performance
>>
>>
>>
>> $> git clone https://github.com/struberg/cdi-performance.git
>> $> cd cdi-performance
>>
>> Just look for the output: ALL THE STUFF TOOK: xxx ms
>>
>>
>>
>>
>> The default profile runs with owb-1.2.6 which is currently used in
>> TomEE-1.7.1:
>>
>> $> mvn clean install
>>
>> If you have OWB trunk installed you can also try the performance of
>> OWB-1.5.0-SNAPSHOT:
>> $> mvn clean install -POWB15
>>
>>
>> There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
>> $> mvn clean install -POWB11 -Dowb.version=1.1.8
>>
>>
>> The numbers of the Reference Implementation (RI: Weld) can be tested via
>> $> mvn clean install -PWeld
>>
>> but take your time and let it run - no it doesn't hang ;)
>>
>>
>>
>> The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and
>> similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the
>> latest RI version.
>>
>>
>> Feel free to debug into it if you don't believe our sheer crazy
>> performance!
>>
>> As a result of this performance I was able to serve FAT applications with
>> BIG pages (huge JSF datatables) within under 150ms where other EE
>> containers took 2 seconds++...
>>
>>
>>
>> LieGrue,
>> strub
>>
Re: CDI container performance
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Wow, very impressive. I'm glad I'm using TomEE+ 1.7.1 (for now) and looking
forward to TomEE+ 2.x.
Questions below,
- OWB-1.5.0: 13 ms (no this is NOT a hoax, it's due to our proxy caching
[1]...)
All with Java8.
Currently trying to run it on other boxes to rule out some misconfiguration
[1] For @ApplicationScoped beans our proxies resolve the contextual
instance only once. Thus you get the benefits of a Proxy (serializability,
interceptors, decorators, cycle prevention, shield against scope
differences) for the costs of (almost) native invocation (Creating
'underTest' via new instead of the CDI bean will run the test in 8ms).
OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
1.7.x releases?
@ApplicationScoped? interesting, I can remember you sending a
recommendation (to me via this list) about caching data in my app, and I
did that in my (CDI) @ApplicationScoped bean. Thanks Mark! :)
On Tue, Oct 21, 2014 at 5:37 AM, Mark Struberg <st...@yahoo.de> wrote:
> Hi!
>
> Yesterday I wrote a small micro benchmark to test the performance of some
> CDI containers. The outcome was pretty stunning - but best if you run it
> yourself:
>
> https://github.com/struberg/cdi-performance
>
>
>
> $> git clone https://github.com/struberg/cdi-performance.git
> $> cd cdi-performance
>
> Just look for the output: ALL THE STUFF TOOK: xxx ms
>
>
>
>
> The default profile runs with owb-1.2.6 which is currently used in
> TomEE-1.7.1:
>
> $> mvn clean install
>
> If you have OWB trunk installed you can also try the performance of
> OWB-1.5.0-SNAPSHOT:
> $> mvn clean install -POWB15
>
>
> There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
> $> mvn clean install -POWB11 -Dowb.version=1.1.8
>
>
> The numbers of the Reference Implementation (RI: Weld) can be tested via
> $> mvn clean install -PWeld
>
> but take your time and let it run - no it doesn't hang ;)
>
>
>
> The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and
> similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the
> latest RI version.
>
>
> Feel free to debug into it if you don't believe our sheer crazy
> performance!
>
> As a result of this performance I was able to serve FAT applications with
> BIG pages (huge JSF datatables) within under 150ms where other EE
> containers took 2 seconds++...
>
>
>
> LieGrue,
> strub
>
Re: CDI container performance
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Wow, very impressive. I'm glad I'm using TomEE+ 1.7.1 (for now) and looking
forward to TomEE+ 2.x.
Questions below,
- OWB-1.5.0: 13 ms (no this is NOT a hoax, it's due to our proxy caching
[1]...)
All with Java8.
Currently trying to run it on other boxes to rule out some misconfiguration
[1] For @ApplicationScoped beans our proxies resolve the contextual
instance only once. Thus you get the benefits of a Proxy (serializability,
interceptors, decorators, cycle prevention, shield against scope
differences) for the costs of (almost) native invocation (Creating
'underTest' via new instead of the CDI bean will run the test in 8ms).
OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
1.7.x releases?
@ApplicationScoped? interesting, I can remember you sending a
recommendation (to me via this list) about caching data in my app, and I
did that in my (CDI) @ApplicationScoped bean. Thanks Mark! :)
On Tue, Oct 21, 2014 at 5:37 AM, Mark Struberg <st...@yahoo.de> wrote:
> Hi!
>
> Yesterday I wrote a small micro benchmark to test the performance of some
> CDI containers. The outcome was pretty stunning - but best if you run it
> yourself:
>
> https://github.com/struberg/cdi-performance
>
>
>
> $> git clone https://github.com/struberg/cdi-performance.git
> $> cd cdi-performance
>
> Just look for the output: ALL THE STUFF TOOK: xxx ms
>
>
>
>
> The default profile runs with owb-1.2.6 which is currently used in
> TomEE-1.7.1:
>
> $> mvn clean install
>
> If you have OWB trunk installed you can also try the performance of
> OWB-1.5.0-SNAPSHOT:
> $> mvn clean install -POWB15
>
>
> There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
> $> mvn clean install -POWB11 -Dowb.version=1.1.8
>
>
> The numbers of the Reference Implementation (RI: Weld) can be tested via
> $> mvn clean install -PWeld
>
> but take your time and let it run - no it doesn't hang ;)
>
>
>
> The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and
> similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the
> latest RI version.
>
>
> Feel free to debug into it if you don't believe our sheer crazy
> performance!
>
> As a result of this performance I was able to serve FAT applications with
> BIG pages (huge JSF datatables) within under 150ms where other EE
> containers took 2 seconds++...
>
>
>
> LieGrue,
> strub
>
Re: CDI container performance
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Wow, very impressive. I'm glad I'm using TomEE+ 1.7.1 (for now) and looking
forward to TomEE+ 2.x.
Questions below,
- OWB-1.5.0: 13 ms (no this is NOT a hoax, it's due to our proxy caching
[1]...)
All with Java8.
Currently trying to run it on other boxes to rule out some misconfiguration
[1] For @ApplicationScoped beans our proxies resolve the contextual
instance only once. Thus you get the benefits of a Proxy (serializability,
interceptors, decorators, cycle prevention, shield against scope
differences) for the costs of (almost) native invocation (Creating
'underTest' via new instead of the CDI bean will run the test in 8ms).
OWB-1.5.0 is and/or will be bundled with TomEE+ 2.x 'and' future TomEE+
1.7.x releases?
@ApplicationScoped? interesting, I can remember you sending a
recommendation (to me via this list) about caching data in my app, and I
did that in my (CDI) @ApplicationScoped bean. Thanks Mark! :)
On Tue, Oct 21, 2014 at 5:37 AM, Mark Struberg <st...@yahoo.de> wrote:
> Hi!
>
> Yesterday I wrote a small micro benchmark to test the performance of some
> CDI containers. The outcome was pretty stunning - but best if you run it
> yourself:
>
> https://github.com/struberg/cdi-performance
>
>
>
> $> git clone https://github.com/struberg/cdi-performance.git
> $> cd cdi-performance
>
> Just look for the output: ALL THE STUFF TOOK: xxx ms
>
>
>
>
> The default profile runs with owb-1.2.6 which is currently used in
> TomEE-1.7.1:
>
> $> mvn clean install
>
> If you have OWB trunk installed you can also try the performance of
> OWB-1.5.0-SNAPSHOT:
> $> mvn clean install -POWB15
>
>
> There is also a profile -POWB11 for testing OpenWebBeans-1.1.x.
> $> mvn clean install -POWB11 -Dowb.version=1.1.8
>
>
> The numbers of the Reference Implementation (RI: Weld) can be tested via
> $> mvn clean install -PWeld
>
> but take your time and let it run - no it doesn't hang ;)
>
>
>
> The version of OWB can be defined as parameter '-Dowb.version=1.2.0' and
> similar for Weld: '-Dweld.version=2.2.5.Final' if you like to test the
> latest RI version.
>
>
> Feel free to debug into it if you don't believe our sheer crazy
> performance!
>
> As a result of this performance I was able to serve FAT applications with
> BIG pages (huge JSF datatables) within under 150ms where other EE
> containers took 2 seconds++...
>
>
>
> LieGrue,
> strub
>
Re: CDI container performance
Posted by Mark Struberg <st...@yahoo.de>.
> * The method 'executeInParallel' uses 'Thread.run'
Oh gosh, txs for catching that. I now did a proper start().
But the numbers did not change much in relation to each other.
By doing so Weld now even blows up with a NPE, so I guess they have some cuncurrency issue under heavy load.
[main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
Exception in thread "Thread-3" java.lang.NullPointerException
at org.apache.deltaspike.cdise.weld.ContextController.startRequestScope(ContextController.java:147)
at org.apache.deltaspike.cdise.weld.WeldContextControl.startRequestScope(WeldContextControl.java:161)
at org.apache.deltaspike.cdise.weld.WeldContextControl.startContext(WeldContextControl.java:70)
at at.struct.cdi.performance.CdiPerformanceTest$1.run(CdiPerformanceTest.java:56)
at java.lang.Thread.run(Thread.java:745)
> * Furthermore the start of the Threads should be done in a separate
> loop.
Did that as well now.
I've already updated my github repo with start() and the separate loop.
> * Apart from this the testcase is a little bit skewed as it used
> application scopes.
I gonna add the same for @RequestScoped
We should also add the following use cases
* class with an interceptor annotation on a single method, invoking the intercepted method
* class with an interceptor annotation on a single method, invoking a NON-intercepted method
* class with an interceptor annotation on the class, invoking a method on it
Feel free to ship patches
Just collecting the new numbers and will ping when I'm done.
LieGrue,
strub
> On Tuesday, 21 October 2014, 12:21, Daniel Kasmeroglu <da...@kasisoft.net> wrote:
> > Am 21.10.2014 um 11:37 schrieb Mark Struberg:
>
>> Hi!
>>
>> Yesterday I wrote a small micro benchmark to test the performance of some
> CDI containers. The outcome was pretty stunning - but best if you run it
> yourself:
>>
>> https://github.com/struberg/cdi-performance
>>
>
> First of all I didn't check the repo on my system. I only looked at the
> source via the browser so here are some remarks:
>
> * The method 'executeInParallel' uses 'Thread.run' which just
> invokes
> the Runnable within the Thread. Therefore it's NOT executing in parallel.
>
> * Furthermore the start of the Threads should be done in a separate
> loop. Otherwise the system setup of the Thread (the VM management) will
> be mixed into the measurements. The beginning of the measurement could
> be placed after the thread creation:
>
> -> Thread[] threads = init
> -> begin = nanos
> -> threads.start
> -> threads.join
> -> end = nanos
>
> * Apart from this the testcase is a little bit skewed as it used
> application scopes. For a comparison with other frameworks it's
> necessary to use a representative set of data points which isn't the
> case for application scopes as they're usually only amount to a small
> fraction of all beans. It would be nice to know about the ratios between
> the scopes in real life applications in order to design appropriate
> scenarios.
>
>
> Best regards
>
> Daniel Kasmeroglu
>
Re: CDI container performance
Posted by Daniel Kasmeroglu <da...@kasisoft.net>.
> But OWB is a fun project of a few spare time hackers without
> any big $Co backing it, so please feel free to get involved ;)
>
I'm trying but I'm not sure whether it makes sense for me to
invest my time in this project (and unfortunately there's no
big $Co behing me, too).
Best regards
Daniel Kasmeroglu
Re: CDI container performance
Posted by Mark Struberg <st...@yahoo.de>.
Actually all CDI containers use proxies for NormalScoped beans. This is mandated by the spec. We also only cache 1 instance for all ApplicationScoped proxies of the same type. So I profiled (using YourKit profiler) that OWB allocates WAY less temporary objects - what results in a fraction of the gc utilisation of other CDI containers.
Of course this is only at runtime. I did not yet focus much on startup for my optimisations.
I think OWB still can get heavily improved in the area of CDI events for example.
But OWB is a fun project of a few spare time hackers without any big $Co backing it, so please feel free to get involved ;)
LieGrue,
strub
> On Tuesday, 21 October 2014, 12:27, Daniel Kasmeroglu <da...@kasisoft.net> wrote:
> > A missing point:
>
> * Since the container is using proxies to improve the performance it's
> necessary to take the additional memory cost into account. Especially
> the ratio between performance gain and memory cost. If the memory costs
> are too high it might backfire on systems with low memory due to things
> like paging etc. Although I doubt that telling from my experience the
> JBoss server is a cheaper choice here ;-)
>
>
>
> Best regards
>
> Daniel Kasmeroglu
>
Re: CDI container performance
Posted by Daniel Kasmeroglu <da...@kasisoft.net>.
A missing point:
* Since the container is using proxies to improve the performance it's
necessary to take the additional memory cost into account. Especially
the ratio between performance gain and memory cost. If the memory costs
are too high it might backfire on systems with low memory due to things
like paging etc. Although I doubt that telling from my experience the
JBoss server is a cheaper choice here ;-)
Best regards
Daniel Kasmeroglu
Re: CDI container performance
Posted by Daniel Kasmeroglu <da...@kasisoft.net>.
Am 21.10.2014 um 11:37 schrieb Mark Struberg:
> Hi!
>
> Yesterday I wrote a small micro benchmark to test the performance of some CDI containers. The outcome was pretty stunning - but best if you run it yourself:
>
> https://github.com/struberg/cdi-performance
>
First of all I didn't check the repo on my system. I only looked at the
source via the browser so here are some remarks:
* The method 'executeInParallel' uses 'Thread.run' which just invokes
the Runnable within the Thread. Therefore it's NOT executing in parallel.
* Furthermore the start of the Threads should be done in a separate
loop. Otherwise the system setup of the Thread (the VM management) will
be mixed into the measurements. The beginning of the measurement could
be placed after the thread creation:
-> Thread[] threads = init
-> begin = nanos
-> threads.start
-> threads.join
-> end = nanos
* Apart from this the testcase is a little bit skewed as it used
application scopes. For a comparison with other frameworks it's
necessary to use a representative set of data points which isn't the
case for application scopes as they're usually only amount to a small
fraction of all beans. It would be nice to know about the ratios between
the scopes in real life applications in order to design appropriate
scenarios.
Best regards
Daniel Kasmeroglu