today we announced a german book about cdi and apache deltaspike.
it's available at http://cdiatwork.irian.at
instead of publishing it at once, we do it step by step.
readers have the chance to provide feedback of any kind. therefore a github issue-tracker is linked in the menu.
if you don't like to do it there, you can also contact me directly. every feedback is very welcome.
Showing posts with label codi. Show all posts
Showing posts with label codi. Show all posts
Monday, March 24, 2014
Thursday, March 20, 2014
migrate codi 1.x to deltaspike 0.6
the myfaces-stack demo at https://github.com/os890/tomee_mf_stack_001 (later added to the tomee examples) is a codi-feature-demo which includes the most important features of codi compacted in few jsf pages and classes. a second branch (https://github.com/os890/tomee_mf_stack_001/tree/codi2ds) in the same repository shows the needed changes to migrate such a codi application to deltaspike (currently v0.6).
update: for upgrading to v0.7, just upgrade the version number of deltaspike (the demo was upgraded already)
update: for upgrading to v0.7, just upgrade the version number of deltaspike (the demo was upgraded already)
Friday, October 25, 2013
migrate codi 1.x to deltaspike 0.5
the myfaces-stack demo at https://github.com/os890/tomee_mf_stack_001 (later added to the tomee examples) is a codi-feature-demo which includes the most important features of codi compacted in few jsf pages and classes. a second branch (https://github.com/os890/tomee_mf_stack_001/tree/codi2ds) in the same repository shows the needed changes to migrate such a codi application to deltaspike (currently v0.5).
Monday, September 9, 2013
boost myfaces codi scopes with owb v1.2
as described in a previous post, it's possible to boost the performance of custom cdi-scopes with apache openwebbeans. owb 1.2 provides a lot of improvements which makes it even more solid and faster.
therefore a new version of the boost-addon is needed.
therefore a new version of the boost-addon is needed.
Monday, July 22, 2013
[add-on] codi scopes for deltaspike
a lot of users use the cdi/jsf scopes provided by myfaces codi (apache myfaces extcdi).
2011/2012 codi merged with some other projects and the result is apache deltaspike.
apache deltaspike is not just a merged code-base. it's nearly a full re-implementation with a similar api, but it contains a lot of cleanups and improvements based on the some lessons learned. that's on of the reasons why the progress slowed down (esp. compared to the development speed of codi). codi was driven and tested by real and large applications (in some cases of early adopters). it didn't contain a huge amount of tests, but it was very well tested (by those applications). apache deltaspike faces a slower adoption rate, because not everybody gets time for a migration (from an already solid stack) and some just wait for v1+ which will provide the final/stable api. however, deltaspike is also very well tested, since there are way more automated tests (compared to codi) and they get executed on a regular basis with different versions of cdi.
one effect of the current development speed is that scopes like grouped-conversations (@ConversationScoped from codi), window-scope (@WindowScoped) and view-access-scope (@ViewAccessScoped) as well as the powerful spi for managing them are still not available and/or not that well tested (in real applications).
since most other parts of codi are already part of deltaspike, it's easy to create a lib based on deltaspike which provides the missing parts. the source-code can be found at os890-cdi-ext and for using it as a dependency (in a maven based build), it's deployed to os890-m2-repository.
for using it just drop the dependencies for codi, add deltaspike (at least core and the jsf-module as well as their dependencies), add os890-cdi-ext (org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-api and org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-impl) and change the imported packages in your application (from org.apache.myfaces.extensions.cdi.[...] to org.apache.deltaspike.[...] and org.os890.cdi.ext.[...]).
apache deltaspike is not just a merged code-base. it's nearly a full re-implementation with a similar api, but it contains a lot of cleanups and improvements based on the some lessons learned. that's on of the reasons why the progress slowed down (esp. compared to the development speed of codi). codi was driven and tested by real and large applications (in some cases of early adopters). it didn't contain a huge amount of tests, but it was very well tested (by those applications). apache deltaspike faces a slower adoption rate, because not everybody gets time for a migration (from an already solid stack) and some just wait for v1+ which will provide the final/stable api. however, deltaspike is also very well tested, since there are way more automated tests (compared to codi) and they get executed on a regular basis with different versions of cdi.
one effect of the current development speed is that scopes like grouped-conversations (@ConversationScoped from codi), window-scope (@WindowScoped) and view-access-scope (@ViewAccessScoped) as well as the powerful spi for managing them are still not available and/or not that well tested (in real applications).
since most other parts of codi are already part of deltaspike, it's easy to create a lib based on deltaspike which provides the missing parts. the source-code can be found at os890-cdi-ext and for using it as a dependency (in a maven based build), it's deployed to os890-m2-repository.
for using it just drop the dependencies for codi, add deltaspike (at least core and the jsf-module as well as their dependencies), add os890-cdi-ext (org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-api and org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-impl) and change the imported packages in your application (from org.apache.myfaces.extensions.cdi.[...] to org.apache.deltaspike.[...] and org.os890.cdi.ext.[...]).
Wednesday, May 1, 2013
the migration to tomee is easy
recently i created an example for tomee.
its origin is an example which used the same java-ee parts you find in tomee out-of-the-box, but configured manually for a servlet container like tomcat. the biggest change i had to do was to drop most dependencies. i just had to keep myfaces codi and extval. besides adding org.apache.openejb:javaee-api as provided dependency, i also added org.apache.openejb.maven:tomee-maven-plugin to start tomee and deploy the example with:
mvn tomee:run.
in the code i could keep everything as it was (the cleanup i did wasn't a required step to get it up and running with tomee). in case of the config i just had to drop some parts in web.xml and persistence.xml.
the rest worked immediately!
its origin is an example which used the same java-ee parts you find in tomee out-of-the-box, but configured manually for a servlet container like tomcat. the biggest change i had to do was to drop most dependencies. i just had to keep myfaces codi and extval. besides adding org.apache.openejb:javaee-api as provided dependency, i also added org.apache.openejb.maven:tomee-maven-plugin to start tomee and deploy the example with:
mvn tomee:run.
in the code i could keep everything as it was (the cleanup i did wasn't a required step to get it up and running with tomee). in case of the config i just had to drop some parts in web.xml and persistence.xml.
the rest worked immediately!
Monday, April 22, 2013
one container everywhere
based on the title you might think that this post is about spring. but it's about cdi with some references to spring/guice/... . however, it is not about spring vs cdi. it's just about wrong myths about cdi (compared to other containers like spring-core/guice/...)
esp. spring and cdi are so close that you can do almost everything with cdi what you can do with spring and the other way round. your project won't fail because you used one of it instead of the other one. if you have spring(-core) know-how already, it will take you about 2-3 days to know the same about cdi and the other way round. however, if you are in favour of the spring-framework, a lot of config options, one vendor,... , you should go with it. once you have the right dependency- and config-setup, the productivity with spring will be similar as long as you are aware of some topics like explicit proxy-configs in case of injection of beans with a narrow scope into beans with a wider scope. (that shouldn't be an offence - for sure also cdi has its pitfalls.)
let's have a look at some myths:
with spring/guice/... everything is more flexible, since you just need to replace some jar-files for using a new version.
reality:
the same integration points to run spring/guice/... in your application-server are also available for a custom version of cdi (added in WEB-INF/lib).
you can't upgrade the cdi container in your ee6 server.
reality:
once you picked an ee6 server, you have to use what you have in there.
reality:
you can't use owb in an ee6 server which ships weld per default.
reality:
approach 2:
2.1
exclude all packages via the scan-tag of the http://jboss.org/schema/weld/beans namespace (in beans.xml) -> only owb will find your beans.
2.2
owb is very pluggable. with a custom WebScannerService you can just use a different file-name for the marker file (e.g. owb_beans.xml instead of beans.xml). you just have to copy the default implementation, replace some strings and enable it in openwebbeans.properties. that means weld won't find your beans, but owb will find them (or the other way round for servers which ship owb per default). however, you might have implementations of javax.enterprise.inject.spi.Extension. -> continue with:
approach 3:
this approach can be combined with approach 2. you can veto beans for weld. just inject the bean-manager in your ProcessAnnotatedType observer and veto the bean if the bean-manager class is from weld: https://gist.github.com/os890/5427764
however, you might use a cdi-extension like codi or deltaspike and there it isn't enough to rename the marker-files or filter beans, because e.g. BeanManagerProvider will find the BeanManager of weld or of owb. since there is no rule (if both are in the classpath), the behaviour would be random. so you have to patch such cdi-extensions. e.g.: https://gist.github.com/os890/5427831
cdi is hard(er) to use, because you don't get a reference to the container.
reality:
that's an easy task with owb as well as with weld. you can do it on your own or just use the CDI-Ctrl module provided by DeltaSpike. (with cdi 1.1 it will be possible out-of-the-box.)
esp. spring and cdi are so close that you can do almost everything with cdi what you can do with spring and the other way round. your project won't fail because you used one of it instead of the other one. if you have spring(-core) know-how already, it will take you about 2-3 days to know the same about cdi and the other way round. however, if you are in favour of the spring-framework, a lot of config options, one vendor,... , you should go with it. once you have the right dependency- and config-setup, the productivity with spring will be similar as long as you are aware of some topics like explicit proxy-configs in case of injection of beans with a narrow scope into beans with a wider scope. (that shouldn't be an offence - for sure also cdi has its pitfalls.)
let's have a look at some myths:
myth #1
statement:with spring/guice/... everything is more flexible, since you just need to replace some jar-files for using a new version.
reality:
the same integration points to run spring/guice/... in your application-server are also available for a custom version of cdi (added in WEB-INF/lib).
myth #2
statement:you can't upgrade the cdi container in your ee6 server.
reality:
technically you can do it. i did it already with tomee, glassfish3 and as7. the main question here is, if you are allowed to do it and/or you have the needed access to do it.
myth #3
statement:once you picked an ee6 server, you have to use what you have in there.
reality:
a lot of specifications and/or the server itself allow/s to use other implementations. however, in case of cdi the container is integrated very deeply. using an other cdi implementation has the same restrictions as you will face with spring/guice/... . so you can do it, but not with keeping the full (cross-)integration like injecting cdi beans in ejbs. however, you can still use the cdi container to do a (bean-)lookup manually (as you would do with spring/guice/...). (preview: cdi 1.1 offers new SPIs which enable servers to provide even more out-of-the-box.)
myth #4
statement:you can't use owb in an ee6 server which ships weld per default.
reality:
as mentioned in myth #3 you can do it with the same restrictions you would face with spring/guice/... concerning (cross-)integration. the following part is tested with glassfish (for as7 you would need a custom WebScannerService which supports the jboss vfs). there are different approaches:
approach 1:
in some cases it's enough just to add owb in WEB-INF/lib. e.g. in combination with jsf the el-resolver of owb will be called before the internal el-resolvers (like it is with spring/guice/...). however, you might face issues with some more restrictive checks done by weld (e.g. bda-rules). -> continue with:
approach 1:
in some cases it's enough just to add owb in WEB-INF/lib. e.g. in combination with jsf the el-resolver of owb will be called before the internal el-resolvers (like it is with spring/guice/...). however, you might face issues with some more restrictive checks done by weld (e.g. bda-rules). -> continue with:
approach 2:
2.1
exclude all packages via the scan-tag of the http://jboss.org/schema/weld/beans namespace (in beans.xml) -> only owb will find your beans.
2.2
owb is very pluggable. with a custom WebScannerService you can just use a different file-name for the marker file (e.g. owb_beans.xml instead of beans.xml). you just have to copy the default implementation, replace some strings and enable it in openwebbeans.properties. that means weld won't find your beans, but owb will find them (or the other way round for servers which ship owb per default). however, you might have implementations of javax.enterprise.inject.spi.Extension. -> continue with:
approach 3:
this approach can be combined with approach 2. you can veto beans for weld. just inject the bean-manager in your ProcessAnnotatedType observer and veto the bean if the bean-manager class is from weld: https://gist.github.com/os890/5427764
however, you might use a cdi-extension like codi or deltaspike and there it isn't enough to rename the marker-files or filter beans, because e.g. BeanManagerProvider will find the BeanManager of weld or of owb. since there is no rule (if both are in the classpath), the behaviour would be random. so you have to patch such cdi-extensions. e.g.: https://gist.github.com/os890/5427831
myth #5
statement:cdi is hard(er) to use, because you don't get a reference to the container.
reality:
that's an easy task with owb as well as with weld. you can do it on your own or just use the CDI-Ctrl module provided by DeltaSpike. (with cdi 1.1 it will be possible out-of-the-box.)
Thursday, November 8, 2012
Tuesday, April 10, 2012
12th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 12th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.5!
Thursday, February 16, 2012
11th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 11th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.4!
Wednesday, January 25, 2012
codi meets tomee
recently the open-ejb team released beta2 of tomee v1.
tomee is already optimized a lot. today we saw an issue during the deployment of a codi demo to tomee. thx to romain manni-bucau we found the issue pretty quickly. due to an optimization tomee filters myfaces-* jar files to improve the scanning performance. so you just have to rename the jar file(s) of codi until the issue gets fixed.
(or manually patch org\apache\openejb\config\NewLoaderLogic.class in webapps\openejb\lib\openejb-core-4.0.0-beta-2.jar)
furthermore, we will add an integration test to tomee to avoid that it happens again.
so have fun with myfaces codi on tomee!
tomee is already optimized a lot. today we saw an issue during the deployment of a codi demo to tomee. thx to romain manni-bucau we found the issue pretty quickly. due to an optimization tomee filters myfaces-* jar files to improve the scanning performance. so you just have to rename the jar file(s) of codi until the issue gets fixed.
(or manually patch org\apache\openejb\config\NewLoaderLogic.class in webapps\openejb\lib\openejb-core-4.0.0-beta-2.jar)
furthermore, we will add an integration test to tomee to avoid that it happens again.
so have fun with myfaces codi on tomee!
Wednesday, January 11, 2012
10th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 10th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.3!
Tuesday, December 6, 2011
9th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 9th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.2!
Sunday, August 28, 2011
[scopes] render-scope vs flash-scoped vs codi scopes
frameworks like seam provide a so called render-scope e.g. to use beans after a redirect for rendering the next page. that's very often not enough because beans are usually also needed on a subsequent request to the same page. the flash scope is also not the best solution because it's usually also used to overcome the redirect issue of request scoped beans. therefore, myfaces codi introduced the view-access-scope which keeps beans as long as they are accessed by a view (also supports any kind of ajax scenarios). however, if you really need the behaviour of @RenderScoped, you can use e.g. the @PostRenderView callback to terminate beans (which have one of the codi scopes) manually or you can provide a custom marker and you terminate all beans with this marker automatically in a phase-listener. the needed information is available in the wiki (or just contact the myfaces mailing list, if you need further information about it).
Saturday, August 27, 2011
[myfaces] setup of codi and extval
in the last weeks i saw a lot of users looking for information about setting up and/or configuring extval and/or codi.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
Monday, August 22, 2011
8th release of myfaces-extensions-cdi
The Apache MyFaces team is pleased to announce the 8th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.1!
Monday, August 15, 2011
[scopes] view-scope vs view-access-scope
a lot of people were looking for this information.
you can find the information in the wiki of codi.
however, the short answer is:
the view-scope of jsf2+ is bound to a concrete jsf page. that means: as soon as you navigate to a different page, the state gets lost. that's better than nothing, but not useful for a lot of use-cases. the main use-case which needs it are ajax-requests on a page and the data used by them aren't needed on other pages, but it's pretty easy to break it e.g. with a browser-refresh on a page which stores the data in a view-scoped bean and has no form with input components. (in a previous blog post i described how to use the infrastructure provided by codi to create a session based view-scope to overcome such disadvantages cause by storing view scoped beans as part of the tree-state.)
like with the view-scope view-access-scoped beans are available on a page, but they also exist for the next page. that means: they are forwarded to the next page and get destroyed autom. if they don't get used during the first request of the next page. that's e.g. useful for wizards. if you have a wizard page which doesn't use the bean or you have to support the possibility to interrupt a wizard, you can use the grouped-conversation scope (and even the window-scope) provided by codi. however, due to the powerful api of codi you can also destroy the scope manually at any time (if needed).
you can find the information in the wiki of codi.
however, the short answer is:
the view-scope of jsf2+ is bound to a concrete jsf page. that means: as soon as you navigate to a different page, the state gets lost. that's better than nothing, but not useful for a lot of use-cases. the main use-case which needs it are ajax-requests on a page and the data used by them aren't needed on other pages, but it's pretty easy to break it e.g. with a browser-refresh on a page which stores the data in a view-scoped bean and has no form with input components. (in a previous blog post i described how to use the infrastructure provided by codi to create a session based view-scope to overcome such disadvantages cause by storing view scoped beans as part of the tree-state.)
like with the view-scope view-access-scoped beans are available on a page, but they also exist for the next page. that means: they are forwarded to the next page and get destroyed autom. if they don't get used during the first request of the next page. that's e.g. useful for wizards. if you have a wizard page which doesn't use the bean or you have to support the possibility to interrupt a wizard, you can use the grouped-conversation scope (and even the window-scope) provided by codi. however, due to the powerful api of codi you can also destroy the scope manually at any time (if needed).
Tuesday, August 2, 2011
[benchmark] boost myfaces codi scopes with owb v1.1.1
this is my last blog-entry about the performance of cdi implementations and codi scopes which is planned for the next months. why? you will see it in a minute.
within the last weeks we gave the weld team some hints how they can tweak the performance of their scopes. as you can see in the following benchmark, they improved the performance of std. scopes in weld a lot. the performance of the std. scopes is now pretty much the same as with owb. all differences are within the tolerance. however, the owb team (special thx to mark) is again one step ahead. the next release of owb (v1.1.1) will allow to use a very fast instance cache for custom scopes. based on this feature, i implemented the scope-boost add-on for codi. the result/s you can see in the chart: codi scopes are as fast as the request scope of owb. a nice detail about that: since owb v1.1.1 is faster than v1.1.0, codi scopes (+ add-on) in combination with owb v1.1.1 are faster than the (already very fast) request scope of owb v1.1.0 (you might remember the awesome results of the previous benchmarks).
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results (tolerance: <0,25ms). all application servers were started without changes in the configuration. for producing the other results i used again tomcat v7.0.19. in this benchmark the servers aren't that important, because there is no class of those servers between the method call and the final method of the bean (just the proxies used by the cdi implementation). that means jboss as7 as well as glassfish v3 are just slower because they don't ship the latest version of weld. for sure - if you upgrade your server, you will get a better performance with those servers.
the result:
as mentioned before std. scopes in weld (the currently latest release) and owb have about the same performance. in case of custom scopes owb can be way faster in combination with special add-ons for the corresponding custom scopes. the add-ons are needed to reset the cached instances, if the scope ends before the request ends. in case of codi you still have all advantages of codi-scopes as well as the performance of the request scope. that's possible due to the awesome concepts in owb as well as the UnscopeBeanEvent of codi. (please notice that weld v1.1.2 which is called "standalone" in this chart is a newer version compared to weld v1.1.2 shipped with jboss as7 out-of-the-box. the newer version already has the performance improvements mentioned before. that's the reason for the difference (and it isn't related to jboss as7))
for this benchmark i used the simple benchmark which i used for my first post (as well as the same steps to measure the performance). in the previous benchmark i switched to jmeter because users were interested in the overall impact. this time i (again) used the simpler version because of some fluctuations with jmeter tests. besides the typical parameters which can influence the results, load tests are less reproducible e.g. because of several features of modern cpus. however, the previous posts are still valid. after publishing them i re-tested the benchmarks with different systems as well as different jdk implementations, operating systems,... . for sure the results differed a bit, but the overall result was more or less the same (esp. the ranking). however, as mentioned in the previous posts as well as in this post, these benchmarks should give you a basic impression. you might see a bit different results on your system, but the overall result is usually the same - esp. the basic messages illustrated by this benchmark:
- owb is innovative, pluggable and fast
- owb + codi == just awesome
- weld got a lot faster in the latest release
- servers which bundle old versions of weld are slower because they depend on the performance of those versions -> update the versions as soon as you can and you will increase the performance of your applications deployed to those servers for free!
within the last weeks we gave the weld team some hints how they can tweak the performance of their scopes. as you can see in the following benchmark, they improved the performance of std. scopes in weld a lot. the performance of the std. scopes is now pretty much the same as with owb. all differences are within the tolerance. however, the owb team (special thx to mark) is again one step ahead. the next release of owb (v1.1.1) will allow to use a very fast instance cache for custom scopes. based on this feature, i implemented the scope-boost add-on for codi. the result/s you can see in the chart: codi scopes are as fast as the request scope of owb. a nice detail about that: since owb v1.1.1 is faster than v1.1.0, codi scopes (+ add-on) in combination with owb v1.1.1 are faster than the (already very fast) request scope of owb v1.1.0 (you might remember the awesome results of the previous benchmarks).
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results (tolerance: <0,25ms). all application servers were started without changes in the configuration. for producing the other results i used again tomcat v7.0.19. in this benchmark the servers aren't that important, because there is no class of those servers between the method call and the final method of the bean (just the proxies used by the cdi implementation). that means jboss as7 as well as glassfish v3 are just slower because they don't ship the latest version of weld. for sure - if you upgrade your server, you will get a better performance with those servers.
the result:
as mentioned before std. scopes in weld (the currently latest release) and owb have about the same performance. in case of custom scopes owb can be way faster in combination with special add-ons for the corresponding custom scopes. the add-ons are needed to reset the cached instances, if the scope ends before the request ends. in case of codi you still have all advantages of codi-scopes as well as the performance of the request scope. that's possible due to the awesome concepts in owb as well as the UnscopeBeanEvent of codi. (please notice that weld v1.1.2 which is called "standalone" in this chart is a newer version compared to weld v1.1.2 shipped with jboss as7 out-of-the-box. the newer version already has the performance improvements mentioned before. that's the reason for the difference (and it isn't related to jboss as7))
(the lower - the better)
for this benchmark i used the simple benchmark which i used for my first post (as well as the same steps to measure the performance). in the previous benchmark i switched to jmeter because users were interested in the overall impact. this time i (again) used the simpler version because of some fluctuations with jmeter tests. besides the typical parameters which can influence the results, load tests are less reproducible e.g. because of several features of modern cpus. however, the previous posts are still valid. after publishing them i re-tested the benchmarks with different systems as well as different jdk implementations, operating systems,... . for sure the results differed a bit, but the overall result was more or less the same (esp. the ranking). however, as mentioned in the previous posts as well as in this post, these benchmarks should give you a basic impression. you might see a bit different results on your system, but the overall result is usually the same - esp. the basic messages illustrated by this benchmark:
- owb is innovative, pluggable and fast
- owb + codi == just awesome
- weld got a lot faster in the latest release
- servers which bundle old versions of weld are slower because they depend on the performance of those versions -> update the versions as soon as you can and you will increase the performance of your applications deployed to those servers for free!
Sunday, July 17, 2011
[benchmark] myfaces codi scopes - weld vs owb part 3
in the previous benchmark i basically compared the scope performance of owb and weld with direct calls. this time i'm using jmeter to measure the performance under heavy load of a whole page. in the previous benchmarks the results were pretty stable. that's different this time. the results fluctuate way more and with some servers i (sometimes) got an OutOfMemoryError (depending on the settings). however, the conditions for the benchmark were the same for all servers:
- starting the server
- opening the page (which will be used for the jmeter tests)
- specifying how many el-expressions should be tested
- starting the jmeter benchmark
pages with 100, 1.000, 5.000 and 10.000 el-expressions were used for the benchmark.
all application servers were started without changes in the configuration. in tomcat mojarra 2.1.3 was used instead of myfaces-core to avoid an impact on the result e.g. due to a differing performance of renderers.
every value-binding in the page queried the value of a conversation scoped bean (codi conversations). this bean delegates the call to an injected request scoped bean. and the request scoped bean delegates to an application scoped bean which caches the list of objects which should be displayed.
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results.
the result:
esp. tests of pages with few el-expressions didn't show a huge difference between the servers, but the results fluctuated more compared to pages with a lot of el-expressions. as you see, tomcat 7 with owb is a bit better than tomcat 7 with weld and jboss as 7. in the end the difference is not big compared to glassfish v3.1.1. the following chart should give you a basic idea about a page which uses 100 value-bindings. that might sound a lot, but a page which contains a table with 4 columns and 15 rows already leads to 60 el-calls during the rendering phase only to display the values (in case of one displayed value per cell). and if you think about the rendered attribute or expressions to switch the formatting within cells dynamically,... you will get over 100 el-calls in the rendering phase very easily.
as mentioned before i benchmarked the page with different amounts of el-expressions. the following chart shows the average of the throughput in percent. the fastest setup (in this case tomcat 7 + owb 1.1.0) is used as measuring staff.
it might be interesting to see the results of the benchmarks above in a different context. the following charts shows the overhead in percentage. a static html page with the same content served by jsf on tomcat 7 is the basis for the comparison and would have 0% (that means: no overhead).
measurements beyond hello word:
there are applications with even larger pages. the following chart shows the numbers for 30.000 value bindings per page. compared to the value-bindings of the benchmark above, it uses more complex bindings like
#{bean1.bean2.bean3.property} instead of directly delegating to a property of the first bean which resolves the final property. as you see owb gets even better with more complex scenarios.
as mentioned before i used the settings which are shipped by the vendors out-of-the-box. since they are different i run the same constellation described above with 1.000 (instead of 30.000) value bindings per page. the following chart shows the result with -Xms128m -Xmx1500m -XX:MaxPermSize=256m (these values are the highest values used at least by one of the servers).
- starting the server
- opening the page (which will be used for the jmeter tests)
- specifying how many el-expressions should be tested
- starting the jmeter benchmark
pages with 100, 1.000, 5.000 and 10.000 el-expressions were used for the benchmark.
all application servers were started without changes in the configuration. in tomcat mojarra 2.1.3 was used instead of myfaces-core to avoid an impact on the result e.g. due to a differing performance of renderers.
every value-binding in the page queried the value of a conversation scoped bean (codi conversations). this bean delegates the call to an injected request scoped bean. and the request scoped bean delegates to an application scoped bean which caches the list of objects which should be displayed.
as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results.
the result:
esp. tests of pages with few el-expressions didn't show a huge difference between the servers, but the results fluctuated more compared to pages with a lot of el-expressions. as you see, tomcat 7 with owb is a bit better than tomcat 7 with weld and jboss as 7. in the end the difference is not big compared to glassfish v3.1.1. the following chart should give you a basic idea about a page which uses 100 value-bindings. that might sound a lot, but a page which contains a table with 4 columns and 15 rows already leads to 60 el-calls during the rendering phase only to display the values (in case of one displayed value per cell). and if you think about the rendered attribute or expressions to switch the formatting within cells dynamically,... you will get over 100 el-calls in the rendering phase very easily.
(the higher - the better)
as mentioned before i benchmarked the page with different amounts of el-expressions. the following chart shows the average of the throughput in percent. the fastest setup (in this case tomcat 7 + owb 1.1.0) is used as measuring staff.
(the higher - the better)
(the lower - the better)
there are applications with even larger pages. the following chart shows the numbers for 30.000 value bindings per page. compared to the value-bindings of the benchmark above, it uses more complex bindings like
#{bean1.bean2.bean3.property} instead of directly delegating to a property of the first bean which resolves the final property. as you see owb gets even better with more complex scenarios.
(the higher - the better)
as mentioned before i used the settings which are shipped by the vendors out-of-the-box. since they are different i run the same constellation described above with 1.000 (instead of 30.000) value bindings per page. the following chart shows the result with -Xms128m -Xmx1500m -XX:MaxPermSize=256m (these values are the highest values used at least by one of the servers).
(the higher - the better)
Friday, July 15, 2011
codi meets scala
werner wrote nice blog entries about using scala in combination with jsf. in the second part he shows the basic approach how to implement the type-safe view-config the scala way. let's hope we will see a follow-up about nice view-config features like multiple inheritance of configs (like a SecuredPages interface).
Subscribe to:
Posts (Atom)