Seam / JSF vs Wicket: performance comparison
January 14, 2009 86 Comments
A while after Seam support for Apache Wicket was announced, I downloaded Seam and took a look at the Wicket example. Then an idea struck – how about doing a performance comparison – I mean, here was the very same application implemented in JSF and Wicket – right? So I decided to write a JMeter script for both the JSF and Wicket versions of the Seam “hotel booking” example and compare results. I started right away but very soon got tired of waiting for app-server re-starts on my trusty laptop (Jetty has really spoiled me) – and it kind of bothered me that the Seam examples were not in Maven 2 layout. Anyway, at some point I decided to re-write an “EJB-free” version of the Seam booking example using just Wicket and JPA. And use Maven and Jetty. And… one thing led to another – and what I ended up doing is this:
- Adapted the Seam JPA example (the one that does not use EJB) as the baseline application. Converted it into a Maven 2 WAR project which can run on Jetty.
- Implemented what I hope is the exact equivalent of the above using only Wicket and JPA, also Maven-ized and Jetty-fied. Decided to also experiment with some of the ideas in this blog post.
- Wrote a JMeter script for both applications taking care to exercise identical functionality.
- Used an Ant script to run the JMeter scripts in batch mode (passing number of concurrent users as a parameter) and start / stop Jetty in sync.
- Automated the entire cycle of running the load test for 1, 5, 10, 15 and 20 concurrent users including some code to parse the JMeter logs and generate a CSV file of tabular results.
- Also included an Ant target that takes a JVM heap dump at the end of the load test – just before the users are logged out and the HTTP sessions killed.
I was able to re-use the official Seam Wicket example to some extent, mainly the HTML files – but the Java side is almost completely re-written. The Seam booking example covers quite a bit of ground from the framework comparison point of view – for example:
- Security – some pages are secured and redirect to a login page
- Templating – some pages inherit from a common layout with a header / footer defined
- Ajax –
- hotel search results refresh as you type and a “busy” image is shown during the Ajax request
- form field validations occur as soon as the field loses focus
- Session scope – some state is stored and retrieved in the session
- Page navigation / state –
- user navigation state transparently managed by the framework
- user should be able to work in multiple concurrent conversations (browser tabs)
- the browser back button should work as expected
- JPA – getting access to the entity manager and transaction management
- Forms – binding, validation and displaying error / info feedback to the user
- Hibernate Validator – annotations on the JPA entity classes are re-used for form-validation
Both sides use the exact same entities, persistence.xml and initial HSQLDB import. I’m using the latest Seam 2.1.1-GA and Wicket 1.3.5. Disclaimer: my Wicket code may not be ideal, and I’ve also experimented with a custom RequestCycle for JPA and tried to use inherited models as far as possible. Instructions on how you can download the source and run the scripts on your local machine are at the end of this blog post.
I may do some follow up blog posts on how the code compares between the Seam / JSF and Wicket implementations, and also share some tips on writing JMeter scripts and automation using Jetty, Ant etc. I’m also expecting to have to make corrections and changes to the code based on feedback. For now, I’ll summarize my observations on performance and memory usage.
Performance:
In the JMeter script, except for the login and logout (first two rows and last row), the actions are executed in a loop ten times for each concurrent user. So if the number of concurrent users is 20, the login and logout actions happen 20 times and the rest 20 x 10 times. The numbers below are average page response time in milliseconds.
Wicket appears to be faster by a wide margin. For two pages (“ajax post search” and “post confirm booking”) the results are a bit closer. This can possibly be explained by the fact that these particular actions display the results from a relatively expensive database query. My amateur profiling attempts suggest that the database query is taking most of the time here.
One thing I have to mention: the “cc number” and “cc name” requests are simulations of the Ajax validations of the credit card number and name fields on the booking form. For these particular requests on the JSF side, the entire form is being POST-ed instead of just the value of the form field being validated when the user tabs out (onblur). So the difference here is quite dramatic. I did try adding ajaxSingle=”true” in the JSF view but it did not appear to work (I used HttpFox while building the JMeter scripts). I can re-post the updated results if someone lets me know what changes need to be made to “book.xhtml” to get the Ajax validation to work as expected.
Memory Usage:
The JMeter script can be told to skip the logout page and I wired up one of the Ant targets to take a JVM heap dump / snapshot as soon as the JMeter script completes. So I can compare what the heap looks like just after a load test when all the concurrent HTTP sessions are alive.
I’m very much a NetBeans user but I have to say that the Eclipse Memory Analyzer is far better than what the built-in NetBeans Profiler offers for looking at JVM heap dumps. Here are some side-by-side screenshots of the heap analysis after running the JMeter script for 20 concurrent users.
“Top Consumers” report below showing the classes that dominate memory usage:
The “dominator tree” report below is very useful to see which objects hold on to the most memory directly as well as indirectly. The column headings after “Class name” are Shallow Heap, Retained Heap and Percentage. Shallow Heap means the memory consumed by a single object and Retained Heap is the sum of shallow sizes of all objects that will be garbage collected if the given object is garbage collected.
Looking at the above two reports we can infer that on the Seam / JSF side, the 20 sessions each take up about 800 KB adding up to around 16 MB total. On the Wicket side the 20 sessions add up to around 1.5 MB. On the Wicket side it is the DiskPageStore that appears to hold the most memory and we can see what is going on here after drilling down a little:
The Wicket DiskPageStore uses SoftReference-s to serialized pages so the memory will be reclaimed by the JVM if needed. And the SerializedPageWithSession holds a WeakReference to the actual page instance (MainPage). You can also spot the byte-array which is the result of page serialization. If a serialized page is requested (perhaps the user hit the browser back-button) and the page is no longer in memory because the SoftReference has been GC-ed – it will be restored from the temp file that the DiskPageStore has been saving pages to.
I’m totally impressed by the Eclipse Memory Analyzer. Here we can see the break-up of the contents of the largest HTTP session on both sides. I think we can safely blame JSF for the lion’s share of memory usage on the left:
Finally, a summary of the heap-dump comparison (for 20 users) collated from the various reports:
Instructions:
Prerequisites:
- JDK 1.5 or greater installed
- Apache Ant installed
- JMeter 2.X available unzipped somewhere (better use latest 2.3.2)
Steps:
- Do a Subversion check out of the source from here: http://perfbench.googlecode.com/svn/trunk/perfbench/
- Create a perfbench/build.properties file that points to your JMeter installation. You can look at the comment in perfbench/build.xml for an example.
- Open a command prompt, change directory to perfbench/seam-jpa
- If running for the first time, use the command “ant jmeter-cycle”. The build script would prompt for the number of threads, so enter “1”. It may take time for all the required JAR files to get downloaded. Once you see Jetty start and stop successfully, you should be all set to run the actual benchmark.
- To start the benchmark run “ant jmeter-cycle-full”. This should take 2 – 3 minutes to run a series of tests for 1, 5, 10, 15 and 20 concurrent users. Results will be dumped into perfbench/target. You can look at the *.csv file at the end for the results.
- You can also run a load test which saves a snapshot of the heap dump towards the end by running “ant jmeter-cycle-heapdump”.
- Repeat the previous 3 steps after changing working directory to perfbench/wicket-jpa
Update: perfbench/build.xml starts Jetty with JVM options “-Xms64m -Xmx64m” and you may need to change this if you want to experiment with more concurrent users.
About Peter Thomas
Incremental Operations 
Pingback: Goliath meet David: Seam/JSF versus Wicket | Wicket in Action
why not compare Seam/JSF with Seam/Wicket? Or did you do that?
@Martijn I did do that initially, just a basic JMeter test. The short answer is yes, I found that Seam/Wicket is faster than Seam/JSF. The reason I did not spend too much time on the Seam/Wicket sample is because a) it was using EJB (I felt that JBoss was not running smoothly on my workstation) and b) because I felt there were some conceptual differences in the implementation of the 2 Seam samples i.e. it was not a level playing field.
The reason why DiskPageStore in Wicket uses that much memory because it is caching last 50 (configurable) serialized pages. However, as number of sessions grows, the amount of memory DiskPageStore takes is more or less constant.
Very nice (keep em comming), good to finally have a comparison.
Thanks for providing this information in such a detailed way with a fairly thorough analysis. It adds to my growing list of reasons to use Wicket.
Excellent post!
This is definitely the best showcase of the power of the Memory Analyzer that I’ve seen outside of SAP.
Ok,I also have a few nice examples at http://kohlerm.blogspot.com/, but I have an unfair advantage.
It’s also the first time I see someone outside of SAP to take a look at the memory usage in detail during a performance test.
I wonder whether you could share the heap dumps.
Note that IMHO the use of Softreferences by Wicket is not optimal because there’s not much control over how long those objects live (only a VM parameter).
@Markus wow, thanks. I don’t need to say more about how much I like the MAT, kudos for all your work on it.
I’d rather not share my heap-dumps – who knows someone like you might get all my environment settings, passwords etc. from it – ok – just kidding :)
Actually you can easily generate them if you follow the instructions at the end of the post – it is completely automated from the command line and should not take you more than 5 minutes or so.
Very interesting article in various aspects. The result is interesting but the method is interesting too. Thanks a lot.
Erm, isn’t this a kinda useless result? Performance comparisons are supposed to vary on variable, while holding the others constant, whereas in this case you’ve varied too many things at the same time.
“Wicket” is not a competitor to “Seam/JSF”. Rather, Wicket is a competitor to JSF. Hell, there’s almost as many reasons to use Seam with Wicket as with JSF.
So I don’t know exactly what the point of this is. It’s like if I did a benchmark of Tomcat/JDBC and then published to the world that it was faster in some cases than Wicket/JPA. Well, duh.
So let’s see a benchmark or Wicket vs. JSF. And then another of JSF with or without Seam, or of Wicket with of without Seam. That might be a bit more useful…
Pingback: Pages tagged "concurrent"
Pingback: Wicket im Vergleich « just IN time
Sorry Gavin at #10 I have no idea why your comment was marked by WordPress as spam and I just approved it.
About your comment that this is a useless result, erm, I humbly disagree, the point here is the Wicket code replaces *both* Seam and JSF and everything else (Entities, JPA, Hibernate config, Jetty, HSQLDB) is constant. Also see comment #3.
Update: see comment #30 also
Note that for me the test scripts for Wicket don’t really work.
After the first iteration (out of 10) I always get 404 errors, which can probably generated more quickly.
@Markus
It is easy to verify that the jmeter script works.
– Open a console window, change to the directory perfbench/wicket-jpa and run “ant jetty-start”
– Open another console window, change to the same directory as above and run “ant jmeter”. Input the number of threads you want, say 10
– You can watch the first console window for log messages. And when the test finishes, point your browser to http://localhost:8080/wicket-jpa/, login and see the bookings created – if you specified 10 threads, you will see 10 x 10 = 100 bookings
– you can optionally use “ant jetty-stop” to shutdown the app-server
… and @Markus another thing you can check are the *.jtl JMeter xml log files dumped in perfbench/target – you should see rc=”200″ (HTTP response code) and rm=”OK” (HTTP response message) for all the samples. It’s all OK when I run the benchmark.
@Peter Thomas
Yes, I did look a the jtl Files. For wicket I always see 404’s after the first iteration of the loop.
@Markus
Strange. I asked a couple of colleagues to try it and it works fine. Maybe you have an old JMeter version?
I have jmeter 2.3.2 running on Vista with Java 1.6.0_10
Pingback: Wicket Impressions, moving from Spring MVC / WebFlow « Incremental Operations
Markus, have you any plans to rewrite this sample app on PHP and perform some performance testing?
@barmaglot no plans for PHP from my side (have no clue about it)
I would rather like to have a GWT implementation.
Pingback: How to start and stop Jetty - revisited « Incremental Operations
Great Comparison!!!
It helps me to be prepared to defend this exact technology choice for a big project we are developing
Thank you very much!!!
thx peter for your comparison!
we also just made performance tests with one page of our online gaming platform:
with seam/jsf our test server handled 20 req/sec, seam/wicket served over 100 pages per second (identical html, similar use of components, page composition, etc)
as always, these results are not representative, but when i looked at several jstacks it was clear why wicket is so much faster:
1) wicket does very little expression evaluation, while jsf spent most of the threads within el-evaluation (the fact that jsf does always uses deferred evaluation had a very bad effect when using facelet components. seam’s enhanced el is also not the fastest one)
2) the stacktraces in wicket are much shorter than those of jsf/facelet: the life cycle of jsf is much more complex and as it expresses the view layer declaratively in facelet pages, in wicket i write the glue code myself.
all in all we were impressed by wicket and will use it for our next features.
@uwejanner
Thanks! I’ve seen others come to the same conclusion as well, for e.g. see this comment:
http://www.nabble.com/Re%3A-Seam-JSF-vs-Wicket%3A-performance-comparison-p21463789.html
Taking a serious look at performance is always a good idea. But you should heed at making generalizations from your results, especially when your comparisons are not equally matched.
@Peter (comment #13), Wicket is not a replacement for Seam/JSF. Wicket and JSF are both component-based web frameworks. Seam is an integration framework. Seam just happens to also address weaknesses in JSF 1 (fixes which are being rolled into JSF 2).
If the term integration framework is too vague, let me provide some tangible examples: conversations and extended persistence contexts, page flows, business processes, charts, file uploads, e-mail templates, advanced security, asynchronous calls. You need all of these things to develop a comprehensive enterprise application.
It’s true that you could develop an application w/o JPA and EJB 3 just as you could develop a web application with only JSP. There is a significant level of convenience and guidance archived by these abstractions…and sometimes it costs a measurable number of (cheap) processor cycles.
With all that said, I’m not criticizing your interest in finding out how to get the best performance for your application. I do challenge you to make the test more scientific.
@Dan: Sounds like you are making a couple of serious allegations:
– “your comparisons are not equally matched”
– “I do challenge you to make the test more scientific”
I have to pose the challenge back to you then. Prove it. All the code is out there as open source. I will be happy to incorporate your feedback and update the comparison if required.
Until then, I have to view your comment as just spin – you are the author of “Seam in Action” and a Seam committer after all ;)
For example, you casually dismiss the cost of abstraction by saying processor cycles are cheap – but here we are discussing response time. Big difference.
Regarding Seam being an “integration framework”, that is easy to debunk. Would you agree that the ability to invoke remote web-services is something that should be expected from such an enterprisey framework? As far as I can tell, Seam does not have any “out of the box” support for invoking remote web services or REST services for that matter. You just have to use some third-party library and Do It Yourself. Which is what Java EE projects have been doing for years.
@Peter, let me clarify my statements because I am certainly not trying to attack your research or persuade you to use Seam. I am saying two things:
– Seam could benefit Wicket just as it benefits JSF. So you have to either compare Wicket with JSF or Seam/Wicket with Seam/JSF. You can’t compare Seam/JSF with Wicket because then you have the overhead of Seam only one one side. The results would be obvious because Seam is going to add a (slight) overhead. The question is whether it’s measurable and whether it can be improved. There is always room for improvement.
– I would dare not say Seam is perfect, which writing a book gives me the credibility to say. Yes, invoking remote web services is a feature that I have wanted for a long time. The RESTeasy integration was a recent addition that partially addresses this need. There is still work to be done.
So to reiterate, I am saying that you don’t have to buy into JSF to use Seam. Seam is something different than component-oriented frameworks–JSF and Wicket. You can absolutely develop applications with only JSF or only Wicket or only JSP. Seam has some nice extras that I find necessary to develop an application.
@Dan – I’ll just quote something you yourself said elsewhere:
So in your own words – Seam support for Wicket is clearly not on par with JSF.
Maybe the only thing Seam could be construed to offer as a “nice extra” for Wicket is the extended persistence context. But let me quote you again:
There you go, no special sauce. My implementation of the hotel booking example extends the Wicket request cycle with just a few lines of code to manage the JPA persistence context.
So help me understand why Seam is required *at all* for Wicket applications.
Pingback: Why you should use the Maven Ant Tasks instead of Maven or Ivy « Incremental Operations
Pingback: doppelpop » Archiv » Wicket Performance
I would have to agree with Dan here. You would need to dump Seam and compare Wicket with JSF or put Seam on both sides in order to get results from the same ‘weight category’.
I, personally would be very curious to see the numbers, although, I can already forecast who will perform.. :)
@Siarhei
Yeah right, not using the same so-called “weight category” somehow magically makes the results here null and void eh ?
Where X = Seam, Y = JSF, Z = Wicket
A = Entities, B = JPA, C = Hibernate, D = Jetty, E = HSQLDB
You are complaining about me doing a perfectly valid comparison of (X + Y) vs (Z) where [ A, B, C, D and E ] are kept constant ? Don’t you realize how ridiculous you sound ?
And please see comment #30 – Seam support for Wicket != Seam support for JSF – it’s that simple.
Oh and if you are interested in a Wicket vs JSF comparison, here you go: https://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/
@Peter, thanks for the information. I use Seam/JSF/Facelets now and although I am convinced it is the best framework to develop in, I am frustrated with it’s performance, though. But I think JSF is the primary cause of the performance problems, not Seam. Anyway, I have been considering using Wicket and your information really compels me to give it a try.
I think people coming to read your post are trying to get a few questions answered: “Which is faster, Wicket or JSF?”, “Which is easier to develop in, Wicket or JSF?”, “Does Seam make Wicket or JSF slow?”. IMO, your post doesn’t answers any of those questions! I am guessing it is JSF and not Seam– but your post doesn’t clarify that. I don’t want to give up Seam, but I also really want to get to the speed that Wicket promises– hopefully, I will be able to use both Wicket and JSF in the same Seam webapp.
Even worse, I think you have some strange bias against Seam. For instance, Dan Allen listed 9 features of what Seam provides that helps it qualify as an enterprise integration framework– you ignored those, but came back with 1 feature that it doesn’t do and claimed that you “debunked” his statement. That’s not debunking because those other features are very valuable.
I am curious to know, how do you do conversations in your Wicket application? Does Wicket come with that built-in? How would you output an Excel file or a PDF file instead of HTML? How would you create jBPM/jPDL page flows? Send a templated email? Schedule an asynchronous task? Seam does all those well, and in both a JEE and non-JEE environment.
For example, I already had a datatable in a JSF page that I wanted to make into an Excel file– it truly took me less than 10 minutes. And that includes learning how to do it for the very first time! Thanks Seam.
@Bob
Thanks for the detailed comment. Regarding questions you feel are not being answered – *shrug* – maybe.
I think I was able to answer the following key questions though:
– Is Wicket faster than Seam + JSF for the *exact* same functionality? Yes.
– Do you need Seam at all when you use Wicket? No.
The hotel-booking sample uses conversations. The support for things like transforming a dataTable to an Excel file is all well and good, but what if you wanted a different format or you wanted to add more columns and customization? In the project I am on right now, there is a requirement for scheduling *plus* a UI to monitor and retry jobs and such. So Seam is not of much help anymore.
IMHO I prefer that the core framework does not spread itself thin by bundling wrappers for various popular Java libraries – but that’s just me, I feel it adds to the learning curve as well. It also looks like Seam would change a bit to align with the WebBeans spec going forward.
@Peter
In effect, you are saying that Wicket is faster than the subset of Seam+JSF that you would use, so Seam isn’t useful to anyone.
I agree that I don’t like a core framework to just wrap popular java libraries. I don’t think that is the case with Seam.
Like in the case with the Excel output, Seam doesn’t just simply wrap JExcelAPI, but it allows you to create very customized excel output through similar facelets xml as you would use for JSF. It’s not simply asking it to render the JSF you already created as Excel!
I also had to create my own job scheduler– and I was thankful that I could build off of Seam’s framework! I store an EL expression and a list of parameters as name/value pairs. When the job is run, it retrieves the name/values and stores them in a Seam event context and then executes the EL expression. It has tons of flexibility and took me one day to complete– but that’s because I was able to leverage Seam.
And of course, Seam packages a nice wrapper around Quartz, so all I needed to schedule a job was to make a call to a method annotated with @Asynchronous, @Expiration and @IntervalDuration. Easy.
@Bob
Let’s agree to disagree on how useful all this integration of 3rd party stuff is in practice. Here are some of my thoughts:
– you make a point that Seam is not just wrapping JExcel – so now since this is “deep” integration – this adds significantly to the learning curve of Seam IMHO
– this also implies that one would not be able to leverage prior experience with JExcel or Apache POI if available. The same goes for Velocity and email templates, Quartz and scheduling etc.
– I already made the point that the Seam project has to now track all these 3rd party projects and maintain the integration points, which is a lot of effort. Seam can never support all possible integrations – and can only make a best guess as to what would be the most commonly needed ones
– the out-of-the-box integration would be fine for simple cases, but in my experience the moment you try to go beyond what is supported, you have to either spend a lot of effort to work around the boundaries – or re-do everything from scratch
The open source project I am involved with called JTrac – uses Wicket for the UI and the app has the following features:
– scheduler using Spring JDK timer integration
– sending of e-mail using custom code and Spring e-mail / SMTP support
– export to Excel using Apache POI
– full-text search using Lucene and Spring modules support
– REST-ful remote API based on Spring MVC (POX over HTTP)
– charting using JFreeChart
Yeah, maybe some of those features weren’t implemented in “less than 10 minutes”. But I hope I made my point :P
@Peter
LOL. You use Spring! It’s funny that make all these arguments against Seam, which can also easily be applied to Spring.
First you argue that Seam is a thin wrapper, and thin wrapper’s are useless. Then you argue that if they aren’t thin, then they are “deep” integrations… which are too difficult to learn. The Seam excel functionality is neither a thin wrapper or a “deep” integration.
If you are going to argue these things about Seam, then the same should apply for Spring.
When you boil it down, a Spring/Wicket solution is not altogether that much different than a Seam/Wicket solution. I would be willing to bet that as far as learning curves go, that someone using Seam/Wicket would get further faster than someone using Spring/Wicket. And I would hope that the Seam/Wicket would be faster than the Spring/Wicket… but there aren’t any tests out there to prove that. Just Seam/JSF vs Spring/Wicket. :)
@Bob
LOL all you want but for the record, 2 of those integrations (POI, JFreeChart) are direct usage of libraries and has nothing to do with Spring. Nice try.
It is pretty clear now that you are clutching at straws trying to justify using Seam along with Wicket. At least you agree that JSF sucks :P
By the way IMHO the real reason why Seam *has* to provide wrappers on top of Java libraries to make things like Excel and PDF views easier for JSF is due to the declarative nature of JSF where you work in XML instead of in pure Java.
That explains why all this integration is available for Seam-JSF and not for Seam-Wicket. Go ahead and use Seam with Wicket if you insist. I certainly won’t.
@Peter
Sorry you feel I am clutching at straws– I am just one developer who suffered under Spring’s xml hell who found a much better way, Seam. I am always looking for better ways to do things, which is why I am looking into trading in a very nice JSF developer environment to get Wicket performance.
I would also trade in Seam in a heartbeat if there was a better solution, but so far, Seam has not failed me. I have found the extra “plugins” that Seam provides, such as for creating pdfs, excel, handling timers, handling security, etc to be very useful.
If I were using Spring, I would do the same thing. I would also use it’s “plugins” for email support and timer integration, and MVC support– just as you have done.
IMHO Seam provides wrappers on top of java libraries for the same reason Spring does– because it reduces developer time and code complexity.
Anyway, the reason I came to your post was to figure out whether there was something wrong with Seam’s performance, in which case I would look to switch from it. It looks like JSF is the cause of the performance problems and so I will happily stick with Seam.
I am still appreciative that you spent the time to do a comparison. I only wish I had the time to do a Spring/Wicket to Seam/Wicket comparison!
@Bob
There you go again, totally ignoring the fact that I had integrated third party libraries without Spring. Again ignoring the fact that Seam-Wicket support does not include email, Excel, PDF views etc.
in our performance comparison (see my comment above) we used both wicket and jsf together with SEAM; if used correctly (e.g. proper use of @Unwrap and @BypassInterceptors) SEAM does not add a significant performance penalty to the mix; jsf is the problem, not SEAM;
if you really benefit from SEAM’s features – use it!
for us, one of the reasons to use seam/wicket was the “hot deployment” feature, which really speeded up development time – no more redeploy/restart of the webapp, especially when the IOC container startup takes long time. didnt find sth similar in the spring world (but havent tried javarebel yet…)
cheers, uwe!
Pingback: JSF sucks « Incremental Operations
I know this thread is a little old now, but I suspect others who are interested in how wicket and seam compare will find it. For the record, as others have pointed out, it’s the wrong comparison.
It’s more like wicket vs. JSF+Facelets and/or Spring “vs” Seam (although Spring and Seam can be used together). If I were thinking of replacing a lot of the services I get from Seam (and I’m not), I would likely look to Spring. It seems to me that they are both most useful for knitting/injecting things together and for making powerful technologies easier to use.
I might look to wicket regardless as it works nicely with both Seam and Spring. It’s true that the Seam documentation is JSF heavy/biased, but I think that has more to do with timing. The core of seam has little to do with JSF/Facelets; it just has great support for JSF/Facelets. Seam now has very good support for Wicket (the core annotations work and their are wicket specific annotations and a seam-wicket.jar in the distro). I would also expect to see greater support in the future (e.g., seam-gen support would be killer or, perhaps better, support for wicket/seam in the wicket maven stuff).
Seems like Seam has a wrap as being heavier than it actually is. I think that’s because it has great support for a bunch unwieldy technologies. For example, it has elegant support for all that big fat JavaEE stuff and can make that rather large pill easier to swallow. But you can use wicket/html/pojos plus Seam pojo annotations and access most of the best parts of Seam in a super-elegant lightweight fashion with almost no XML.
With regard to JSF/Facelets versus Wicket, for my part, JSF/Facelets at first seems attractive from a DRY perspective, but in practice I find JSF/Facelets restrictive, unintuitive, and byzantine. Plus, simple stuff is way too hard in a guess-what-I’m-thinking sort of way. Maybe I just don’t get it yet — entirely possible.
@Ian – just one comment.
The Wicket side of the comparison is just Wicket + Hibernate (JPA). Nothing else. No Spring, no JSF, no Facelets, no Seam, nothing.
If Wicket can replace Spring, Seam, RichFaces / JSF and Facelets at the same time, and give much better performance – I personally find the results of this comparison interesting and very useful, and so do many others.
It’s a pity that you say “it’s the wrong comparison”. But to each his own, I guess :P
@Peter
I’m not to the “no accounting for taste” point yet… There’s an important point here that I’m not sure you’re grokking. Maybe you are. I’m just not sure.
For me it IS the wrong comparison. I would not use Wicket by itself, as I get too much value from (in my case) Seam. From your numbers I don’t know what the performance impact is of using Seam is as I’m not using JSF/Facelets/Richfaces but instead I’m using Wicket.
So far, I think what you may have demonstrated is that JSF/Facelets/Richfaces is slower than Wicket. Great! I much prefer Wicket to JSF/Facelets/Richfaces. But for me, that’s the comparison. I could use Wicket by itself, but it’d be a lot more work. Why would I do that w/o knowing the perf impact?
Get it?
Ian
@Ian
This “case study” (perhaps the word “comparison” is what you find offensive :) uses the *official* “Hotel Booking” example code – which Seam committers and evangelists have been using for a while to show off the features of Seam.
So pardon me for putting the question back to you: Get it?
Pingback: “Perfbench” update: Tapestry 5 and Grails « Incremental Operations
Pingback: Wicket takes lead in test over Grails, JSF/Seam and Tapestry | Wicket in Action
Peter, frankly, you are biased, your comparison is pointless, you are totally unable to understand other people’s point of view and you behave and argue like a 7-year-old child.
The problem is not SEAM, it’s not Wicket, it’s not even JSF, the problem is you’re a retard.
@Agus LOL. I can live with that ;)
Pingback: Seam / JSF vs Wicket « Wicket Spiders
We have been developing in Seam for about an year now.
We use Seam/JSF/Facelets/Richfaces/JPA.
Our application pages renders very slow. We almost put in so much of effort in our product and relished the “magic” of seam, but we are not able to increase the performance of the page rendering. We tried all the suggestions from experts on “performance tuning in Seam”, but all in vain. Basically seam actions are invoked very fast, but the rendering is way too slow.
Any suggestions/help is greatly appreciated.
@Dinesh We had the same issues: we created a wonderful webapp in the same technology stack as yours. Stresstesting it with JMeter showed up the app ran out of memory with 4 concurrent users. OOPS!
Analysis with a profiler revealed that the JSF component tree gets incredibly big (many megabytes per user). We thought the x in this code fragment would not be part of the JSF tree: x
However, it is. You should use x where possible, because then it really won’t be part of the component tree.
Another thing to bear in mind is that any Seam component without @BypassInterceptors will get all its bijections done every invocation, even if they are Session scoped. You would think that storing a component property in a temporary EL property will tackle this issue, but still everytime the ‘cached’ property gets evaluated, which in turn invokes the Seam component. Google for Seam DTO and try to make Seam components @BypassInterceptors where possible.
If you still have issues, you should use a profiler (we use YourKit, but there’s many good ones) to see which methods get invoked often and which methods are costly.
After a few days tweaking our webapp, it now easily supports 100+ concurrent users and Ajax responses render in a blink of an eye!
My code fragment was not escaped. I tried to say that when using the rendered attribute of s:fragment (or s:[div/span/decorate]), it does not exclude it’s contents from the JSF tree.
You should use c:if with it’s test attribute.
There is a caveat though which may prevent the content of c:if not to show up when the condition evaluates to true after a postback, but that’s a nice Google excercise ;)
@Eddy, first thanks a lot for your response.
We had similar memory issues and we are now trying to disable interceptors (i.e @BypassInterceptors) also use Seam DTO. We will also use YourKit as per your suggestion.
To be very frank, your response was faster than Googling…
if possible please email to yourdinu@gmail.com, so that we can talk over there…and not pump messages into this forum irrelevantly….
Yet another Wicket fanboy spams about how great the Wicket is… one less reason to consider a framework with such immature followers.
Pingback: Альтернативы JSF для Seam | Alexander Shchekoldin "all in one" blog
Tried building a richfaces/facelets/seam CMS application. It was a battle of epic proportions, even with RedHat JBoss developer support it nearly burnt me out. Long story short I’m now looking at other frameworks.
Seam is a very good framework, Gavin and team have done a wonderful job in developing a excellent framework and conversation scope and workspace management is definetly a eye opener for many J2EE developers.
The ThreadLocal based context is a core feature of Seam and i really love the annotation stuffs. One thing which worries me is the Home , List framework components which are supposed to be wrapper on JPA entities but extending Controller in a hierarchy which violates the seperation of concerns [UI and persistence], i shall not like to see methods like addcookies, addmessages in these framework classes which are meant to be DAO specific.
Wicket brings refreshment for those who are tired to work with tag libraries and JSF components.
“Wicket in Action” nice guide to understand wicket framework.
The chapters are short and descriptive.
thanks to Martijn, Eelco & Peter for their effort.
The title should read “Seam / Richfaces vs Wicket: performance comparison”.
As the example benchmark takes a sample Seam Richfaces and compares it against a sample Seam Wicket application. Richfaces is not the only JSF component library and library will perform differently.
For the benchmark did you:
1.) Remove the jboss-seam-debug.jar
2.) Change the facelets.DEVELOPMENT in the web.xml to false.
I’m not sure, why the size of the ssssion was so large. Might because the seam debug jar file was storing extra information in the session.
Did you dig deeper in to the heap dump file to see what was being stored in there?
@markcoffin
Yes to 1) and 2) [link]. You can download the source code and easily run the benchmark yourself if you want.
Was this test using only 20 sessions at a time, allocating 1.5M, meaning 75K a session? If seam takes 800K instead of 1.5M it is the winner in the memory category. As much as we like wicket, the first thing we did is to make it stateless and turn off any disk persistence. Why have a solution when you can just remove the problem?
@Nitin
>> Was this test using only 20 sessions at a time, allocating 1.5M, meaning 75K a session
No.
You compare Seam/JSF against Wicket. Of course seam adds overhead. The results you got are reasonable. But in software engineering and design it is a very important task to analize trade offs. It performs slower but offers greater flexibility and ease of development.
Of course you can program a simple test like this in plain jsp and would perform faster than both, wicket and Seam/JSF so i guess that we should all use plain JSP for web applications.
The Seam factor should be removed from the experiment. So JSF vs Wicket. JSF+SEAM is a different animal from just JSF.
Excelent comparison!
Really very nice!
Good work!
great for wicket comparison to JSF Seam
We’ve been using Wicket since 2006 mainly for its high developer productivity and the production of very maintainable code (not to mention it avoids all that JSP/Struts/XML config unmaintainable nonsense that occurred in every JSP app I was *coerced* into working on).
Wicket performance has never been an issue for us and it’s comforting to know why now!
Pingback: Load testing Seam-Booking with JMeter « Le Blog d'Akram Ben Aissi
I wonder how much difference would make other JSF implementations
Pingback: Confluence: External Projects
Pingback: Apache Wicket: Une véritable séparation des couches
Pingback: JavaPins
I almost never comment, however I looked at a few of the remarks on this page Seam / JSF vs Wicket: performance comparison | Incremental Operations.
I actually do have a couple of questions for you if it’s allright. Is it simply me or do a few of these remarks come across as if they are written by brain dead individuals? :-P And, if you are posting on other sites, I’d like to follow anything
new you have to post. Would you post a list of every one of all your social networking sites like your linkedin profile, Facebook page or
twitter feed?
Pingback: Patate Chaude | Apache Wicket: Une véritable séparation des couches
Pingback: Revue de Presse Xebia | Blog Xebia France
This basically suggests that you will be able to eat anything that you
want without the worry of gaining weight. This continues to be not 100% confirmed, but keep tuned.
The thermogenic and stimulants from Adiphene will help your body to
burn the energy which are consumed throughout meals.
Pingback: burn fat
Pingback: product review
Pingback: How to: Choosing a Java Web Framework now? | SevenNet
Pingback: Confluence: Product Info
Pingback: Load testing Seam-Booking with JMeter | Akram Ben Aissi
Pingback: 现在选择Java Web Framework？[关闭]|java问答