“Perfbench” update: Tapestry 5 and Grails
September 14, 2009 75 Comments
I attempted to port the Seam “hotel booking” sample to Grails 1.1.1 as well as Tapestry 5.1, to add to this head-to-head comparison of Apache Wicket and JBoss Seam done earlier this year. You can find the code here: [browse] [SVN]
Here are the relative performance test results (page response time in milliseconds):
Heap-dump comparison for 20 concurrent user / sessions:
I’ll save detailed framework impressions and comparison for a later blog post, and I may need to make updates to the code based on feedback. Here are some overall observations:
- Grails was far more productive than Tapestry 5. This was mainly due to the documentation quality of Grails compared to the scattered and not very well organized Tapestry documentation.
- Ease of writing custom tag-libraries is IMO one of the best things about Grails.
- The two missing rows in the Tapestry performance test results are because I gave up trying to implement form field validation over Ajax when the user “tabs out”. Actually I didn’t implement form-field validation at all because I could not figure out how to integrate Hibernate Validator. Maybe I missed something obvious, do let me know.
- Grails still has some way to go in terms of performance. I am told that significant performance optimizations for GSP will make it into 1.2
- Overall, Wicket is fastest, with Tapestry coming a close second.
- Wicket also takes up the least amount of heap. 31 MB of the Grails heap alone is taken up by instances of the “groovy.lang.ExpandoMetaClass”.
- Session usage of the Seam + JSF combination is significantly higher compared to all the rest, around 760 KB per session.
Thoughts on Tapestry 5
I was very interested in seeing if Tapestry 5 lived up to its promise of significantly better performance and scalability – which is known to come at a cost: a programming model that treats web-pages as static structures that can be “pooled”. One example of what this means is that you can’t rely on constructors anymore so you now have to figure out other ways of re-initializing your server-state (if applicable) after you are handed an instance from the pool. The “magic” of getting a page from the pool or getting hold of request or session scoped variables is all achieved predictably – using annotations.
Another example: due to the way Tapestry does byte-code manipulation – the annotation approach works only for “private” fields and not “protected” ones. I found this out the hard way, encountering an exception when I tried to extend from an abstract base class and re-use code the “old-fashioned” object-oriented way.
There’s a lot more I can go into, but for now, to summarize my experience as a long-time Wicket user trying out Tapestry 5 – the top few differences I found are:
- Having to work around the implications of Tapestry pages being static and “annotation driven” programming like I described above.
- Tapestry does not have the equivalent of Wicket Model-s which give you fine-grained control over the data you need to render (and bind) within a page and how much of it you decide to persist in the session. Model-s are certainly the aspect of Wicket that takes the most getting-used-to, but I have a new-found respect for them now after trying Tapestry.
- I would rate the Ajax infrastructure of Wicket higher: for example Wicket Behavior-s are cleaner compared to Tapestry Mixin-s, and calling / handling Ajax requests (especially when you depend on server-side state) is far easier.
- Tapestry 5 does not have built-in support for web-flow or “conversation scope” so I had to write some code to maintain a map of bookings in the session. BTW I did not have to do this for Grails as I could use WebFlow.
So coming back to the question, does the “Tapestry way” have a distinct advantage and are the quirks of the programming model worth it? The opinion of the Tapestry team on this is pretty clear. Take this quote from the Tapestry home page for example:
In some Tapestry-like frameworks, such as Faces and Wicket, the page structure is more dynamic, at the cost of storing much, much more data in the HttpSession.
Well, looking at the performance comparison results, my personal conclusion is that statements like the above are incorrect. In fact Tapestry seems to take up more heap space than Wicket for the same functionality. Also worth noting are the results of running the Wicket application using the HttpSessionStore instead of the default SecondLevelCacheSessionStore + DiskPageStore:
Because this time, Wicket is faster now even for the “post confirm booking” page. This particular action actually ends up displaying 200 items in an HTML table by the end of the test run for 20 concurrent users, since pagination is not being used.
The benchmark has been designed to be easy for you to run once you check-out the code, refer the end of this blog post for details. The details of the environment I used for the results posted here are as follows:
- java.runtime.version : 1.6.0_16-b01
- java.vm.name : Java HotSpot(TM) Server VM
- java.vendor : Sun Microsystems Inc.
- os.name : Windows XP
- os.version : 5.1
- sun.os.patch.level : Service Pack 3
- Intel Core 2 Duo 3.01GHz
- 3 GB RAM
Feel free to post your results or suggest changes to the code.
About Peter Thomas
Incremental Operations 
great stuff..always good to see hard numbers.
Q: why is post confirm booking for 20 users consistently better in T5?
Overall heap size is not a concern as long as its not crazy – caching stuff is a good thing – Tapestry caches a lot of cruft like page templates and expressions etc.
Not being able to construct pages was a big deal for us in T4 (surprised they didn’t fix this in T5) – they should allow you to construct pages directly and annotate with the page template it should bind and reuse via flyweight.
T4’s page pooling design also meant page instances were replayed to bring back to a required state – caused some nasty rewind issues – but it did save on session space (tho prbly affected overall processing time).
As a final note – I want to give credit to Tapestry for pioneering the first really usable component web-framework – which was why we chose T3 and later T4 several years back. We’ve since moved on to GWT’s rich goodness and haven’t looked back. (tho I did have to build additional tooling & framework support around it, much of which i can happily discard with GWT 2.0 soon).
@SonyMathew
A. “post confirm booking” is better in Wicket if you switch to the HttpSessionStore as I mentioned towards the end of the blog post. This is the point when a new hotel booking is submitted, and the user is shown the main page which reloads the complete list of bookings in the system (without pagination!).
I have heard that for e.g. AntiVirus programs on Windows can get in the way of the Wicket DiskPageStore when it saves stuff to files on disk. I would be interested in knowing if people see radically different results on *nix.
I keep telling people who assume Tapestry/ other frameworks are faster and use less memory: don’t believe what you hear or trust common sense, but measure for your own use cases. We spent a lot of time with Wicket trying to optimize, because we knew it would be one of it’s bottlenecks. Sometimes your potential disadvantage can turn into an advantage I guess :-)
With the Grails application, you did generate a war and deploy it didn’t you? You didn’t run “grails run-app” right? I expect Grails apps to be slower than pure Java, but I’m not sure I would trade developing on Grails for Swing/JFC on Http (i.e. Wicket).
> not sure I would trade developing on Grails for Swing/JFC on Http (i.e. Wicket)
Well, the funny thing is that people don’t use Wicket for efficiency reasons, but rather because they like the statically typed programming model. So it is extra funny that yet again (consistent with benchmarks in the past), Wicket turns out to be pretty efficient, even if that goes against ‘common sense’ of many people.
Of course, if you prefer Grail’s programming model, the performance tradeoff might be well worth it. Buying another machine is no match for needing another developer :-)
> because they like the statically typed programming model
and flexibility and easy of custom component creation etc of course… well, you get my point
What about Stripes?
The Wicket folks really put a lot of thought and effort into reducing the memory usage of the framework, because Wicket places such high emphasis on easy and efficient clustering. Not surprised that memory usage is so low.
Pingback: Twitter Trackbacks for “Perfbench” update: Tapestry 5 and Grails « Incremental Operations [ptrthomas.wordpress.com] on Topsy.com
@Richard Vowles (#4):
Yes, you can look at the Ant script for Grails, it does the equivalent of “grails prod war” as far as I can tell.
What happens when you run ‘grails install-plugin wicket’ ? Do you see a light coming from heaven?
@Jake Mustang
Ha ha. It may be worth taking a look at once Groovy 1.7 is available.
> Session usage of the Seam + JSF combination is significantly higher compared to all the rest, around 760 KB per session.
You should include JSF 2.0 in the mix, who’s spec has gone final. It has significantly improved it’s state saving mechanism to use less memory:
It would be nice to have Stripes and Lift added to the comparison.
@xsonymathew
Heap size matters when you want to host your project on the internet. More memory consuption translates in more money paid.
Great work, really interesting to see these results.
First, nice work.
But why are you comparing 3 “out of the box” web-frameworks with Seam? Seam is a heavyweight extension to the core JSF framework itself. I find this comparison somewhat less useful for that reason. Show me JSF2.
Also, I’m sure that you were using Server side session saving in the Seam example. In order to completely cover JSF’s performance, you should include a benchmark of JSF2 using Client-side state saving. The numbers will be much different in the memory arena.
While I don’t expect it to be faster than Wicket, I’m willing to say I’d find the statistics more sound :)
Good article, will be curious to see how Grails 1.2 stacks up once out
@Lincoln
Actually this whole exercise originated from the Seam hotel-booking sample – and I’m sure the Seam guys won’t take kindly to your comment that it is *not* an “out of the box” framework :P
I’ve taken care to use the exact same versions of JSF and RichFaces used in the latest stable Seam 2.2.0.GA release. Hope that answers your question.
I wouldn’t mind doing a JSF2 version in future once I figure out which component library to pick, which one is more stable etc.
@Peter
Actually that’s not really what I meant — just that you were comparing a large extension framework to three unmodified frameworks. I would consider JSF1.2 or JSF2.0 by themselves to be on the same level.
That’s all I meant :)
@Lincoln
Oh. So then you are suggesting that Seam is responsible for additional overhead and not JSF.
That’s interesting because the Seam guys seemed to be pretty sure it was the other way around in the comments on the previous blog post.
Seam is definitely an improvement. I’m not saying that JSF would be faster in any way. But… I don’t want to argue with you. This was a good post and you did a good job.
I’d just like to see more comparison there :) Especially with the client-side state saving, which effectively reduces the server-memory load to 0 per session (unless you clutter it manually :)
However, I don’t agree with you that JSF sucks ;)
Ok.
@Lincoln
Client side state saving isn’t the only solution for JSF. JSF 2.0’s server side state saving is supposed to use significantly less memory. Since the other web frameworks in this comparison were using server side state saving, the JSF 2.0 tests should too.
Pingback: Top Posts « WordPress.com
@Ryan
Yeah I know, but with that option, I almost guarantee you that JSF’s session state would be as low as or lower than all the others.
JSF2’s state saving has taken a lot from the Seam project.
PS. Glad to see you’re still being active in the community!
@Lincoln
Oh and congrats on your just becoming a member of the JCP. JSF2 Expert Group if I’m not mistaken ? ;)
@Peter & @Ryan
That’s right. Thanks! Ryan actually kicked me off toward getting to this point when he sent my PrettyFaces package info to the expert group team at RedHat.
Are you on twitter?
> Wicket turns out to be pretty efficient, even if that goes against ‘common sense’ of many people.
Grails does not have a compontent tree, JSF does not persist it’s component tree, but do some state saving to compensate this,tapestry does some pooling which add complexity… and wicket?
Wicket takes the direct path and save the state in the only natural way. I am not surprised, that wicket is so far pretty efficient. Every thing else looks like pre-optimization if compared to wicket (not grails).
I would be interested to see CPU usage stats for these runs… I could easily see living with more heap usage if the CPU usage is dramatically lower.
Nice comparisons, although somehow i’m not surprised wicket is declared as the winner. Actually I would be surprised if wicket looses out to anything in an article by Peter Thomas.
At the same time, in articles written by Ed Burns, it’s always JSF that wins and in Rod Johnson’s posting the clear winner is always Spring.
I’m not accusing anyone of anything, but it does make me wonder…
P.s.
JSF most definitaly does not suck ;-)
With Grails I’m actually pretty pleased we aren’t that far off given that we’re competing with Java frameworks. Groovy is a dynamic language after all.
With the optimizations in Grails 1.2 we are seeing up to 300% performance improvements and we hope to get as close to the Java frameworks as possible. That will put Grails in a pretty unique position given that most other dynamic language frameworks (PHP, Rails, Django etc.) are significantly worse performance-wise compared to Java ones.
However, what I would say (and I mentioned this to Peter on Twitter) is that the benchmark is fundamentally flawed. Since it doesn’t take into account JVM warm-up.
Groovy relies heavily on callsite caching and the ability of the JVM to JIT compile bytecode to machine code. For example in my local benchmarks of a “hello world” Grails request using AB I can see performance start out at roughly 100 requests per second for a simple hello world and end up at 800 requests per second after a few minutes of JVM warm-up.
The benchmark here doesn’t take into that account and hence is not valid IMO.
Note: Wicket/Seam/etc. would also almost certainly benefit from JVM warm-up, but probably not quite as much as Grails.
> I’m not accusing anyone of anything, but it does make me wonder…
Peter Thomas has no stake in Wicket other than being a user, so comparing him to Ed Burns and Rod Johnson are off. Also, I haven’t seen such benchmarks from them, so my hunch is that it is your hunch, nothing more than that.
> The benchmark here doesn’t take into that account and hence is not valid IMO.
I haven’t looked at the code, but I would agree that an honest benchmark lets the app warm up more, while still trying to somewhat randomize requests so that you don’t get exact cache hits.
Benchmarks like this are nice to see I guess, but they mean very little in the end… I mean the differences are very minor, and the actual accuracy can always be questioned because its so difficult to produce semantic benchmarks that closely simulate real time use.
What really counts imho is the productivity benefits (or lack thereof) of these frameworks… as the old cliché goes, time is money, I want a web framework that saves me both!!
@Graeme Rocher
> The benchmark here doesn’t take into that account and hence is not valid IMO.
I agree this is probably true.
The test currently is set up so that the very same hotel record is chosen again and again and booked in a loop. I had assumed that this would be sufficient for warming up the JVM. But it looks like JIT compilation to native code takes place only after 10,000 invocations when the JVM has been started with the “-server” argument.
Apparently, this threshold can be changed, so I’ll experiment with this when I get time. I’ll also see if the test can be looped for a given number of minutes and then Jetty restarted without killing the JVM.
@Peter (#34)
> […] they mean very little in the end […] I want a web framework that saves me both
Whether they mean “very little” is debatable. But forget about the benchmark, consider that you now have a side-by-side comparison (with code) of a reasonably complicated application (see prev. blog post for the feature set) – which IMHO is quite useful for all kinds of analysis.
> […] they mean very little in the end […] I want a web framework that saves me both
While I personally agree with that, I often read that people suggest Tapestry is the more efficient choice, and that you should only choose Wicket for productivity. For instance, see the (currently top) answer here: http://stackoverflow.com/questions/657352/difference-between-apache-tapestry-and-apache-wicket
quote:
“My recommendations:
Use Wicket when your pages structure is very dynamic and you can afford spending 10-200 Kbs of HttpSession memory per user (these are rough numbers).
Use Tapestry 5 in cases when you need more efficient usage of resources”
Who knows how many people didn’t pick Wicket because they *think* it will be inefficient.
@Eelco – just looked at the thread you linked above, am glad that at least now some hard data to dispel *that* kind of FUD exists. Tip for those following the link above, click on the “show more” link under the (currently) first answer to see the full discussion.
At least from the memory usage perspective, I would say that the benchmark is sound.
From the response-time perspective, as Graeme pointed out, it is possible that JVM warm-up would benefit Grails more, but for Tapestry and Wicket I’m pretty sure that it is a level playing field.
I do have my doubts though whether JVM warm-up would really have that much of an impact. As far as my understanding goes, the question boils down to a couple of things:
a) Call site caching happens on the first invoke and takes effect for all subsequent calls. So this should have an immediate impact, i.e. not dependent on JVM warm-up.
b) The question is whether the JVM can inline the above calls to give an *additional* performance boost. But isn’t that the same case for the other frameworks then, is what I’m thinking. Okay, maybe having all these call sites hanging around waiting to be optimized is something unique to dynamic languages.
I guess there’s only one way to find out for sure.
@eelco
Peter thomas may not have a direct stake in wicket, but he is known to be a hardcore wicket fan. Somehow in all his articles wicket always wins everything.
Hello,
I’m a Tapestry committer. I’m not going to start any flame wars but I need to defend Tapestry. I strongly believe that Wicket is a beautiful framework. If there were no Tapestry I would be a Wicket user.
But this comparison is somehow unfair. Peter is a Wicket user and a Tapestry beginner. The Tapestry app is written in Wicket-style but not in Tapestry-style. The ”BookingSession” is a mess. In Tapestry you would never store so much data into the session. Tapestry itself reduced the usage of the session to a minimum. Why the hell shall I store the Hotels and Booking in the session?
Furthermore Peter should have used Tapestry components like Grid, BeanDisplay etc. instead of implementing similar functionality by hand.
If Peter would choose Hibernate instead of JPA he would probably reuse the native Hibernate integration (http://tapestry.apache.org/tapestry5.1/tapestry-hibernate/).
This Tapestry modul provides an implementation of HibernateGridDataSource which allows you to create a Grid’s pager without to load all data but only the certain subset.
I’m sure there is more stuff that could be done better in Tapestry but I hadn’t time to have a closer look.
I summary I would say that the comparison is biased by lack of Tapestry knowledge. Peter should better start a contest by describing the app. Someone of the Tapestry community would do a much better job.
Cheers
@Igor
This discussion is important and I’m completely with you on not starting any flame wars.
Actually no. I’ll respond to specific points in detail below, but first I want to make it clear that I did spend some time looking through Tapestry 5 samples and documentation available, and tried my best to come out with a fair comparison.
The answer is simple, because that’s how it is in the baseline application. Keep in mind that the hotel-booking app is not my invention, it is originally a Seam + JSF sample. All three: the Seam, Wicket and Grails versions store the Hotel-s and Booking-s in the session and on the exact same events. Why should the Tapestry one be any different?
Again, the baseline application uses Hibernate Validator for driving form validation and the Grid and BeanDisplay components don’t support this. Now out of the 4 apps, only the Tapestry one has form validation not implemented, and I’m very interested in getting this completed, hopefully with your help. There is a page available with the detailed spec of the baseline Hotel Booking app which I’ve linked to below.
The baseline application uses JPA not Hibernate. I have to mention that I couldn’t find a decent Tapestry 5 sample using JPA anywhere else on the net, maybe I missed something?
Again, look at the baseline application. The Hotel-s are paginated but the Booking-s are not and that’s how it is in all the 4.
Sorry, you’ll have to prove that I lack the required degree of Tapestry knowledge. And yes, I’ve just created a detailed wiki page that describes the app and the rules that implementations should play by – here:
http://code.google.com/p/perfbench/wiki/HotelBookingSpecs
C’mon Peter, you can’t compare frameworks if you don’t use their best features and ignore the best practices of the frameworks.
I most probably would win a boxing fight against Mike Tyson with tied hands behind his back.
Your Tapestry app is not a typical Tapestry application. You adjusted it to be conform with the baseline application. An experienced Tapestry user would never write his app in that way. No wonder that Tapestry doesn’t score well.
If I would compare frameworks I would allow them to use all the weapons they have. I would only specify the use cases, not technologies.
@Igor
Are you saying that the hotel-booking application is not a “typical” Tapestry application?
And are you saying that “best practice” for Tapestry applications is to use Hibernate and not JPA – just because Tapestry 5 does not have built-in JPA support?
Some data had to be stored in the session (manually) since Tapestry 5 does not have “conversation” or “web-flow” support. Perhaps Tapestry best-practice is to choose use-cases that don’t require conversations or wizard-flows?
Actually, after working on it for a while like this, I have come to the conclusion that the hotel-booking sample is a really good representative app for comparing frameworks because it covers quite a lot of ground: e.g. Ajax, Templating, CRUD, form-validation, authentication, wizard-flows, etc.
Keep in mind that (in addition to the original Seam sample) I was able to implement the requirements, screen-by-screen, in 2 other frameworks, Wicket and Grails.
Very interesting article and discussion.
I’d like to voice my appreciation to the commenters for having a constructive and interesting technical discussion on the topic, and NOT turning this into yet another flame war. I don’t take for granted when people are able to avoid personal attacks and useless ego contests. Makes for a much better reading experience.
Congrats and thanks.
As for getting Stripes into this arena, I’d love to work on the implementation but it doesn’t look like I’ll have time in the short term. I am simply overloaded with other projects. However if someone else from the Stripes community cares to contribute, I’ll try to help out.
Cheers,
Frederic Daoud
http://www.stripesbook.com
>> I’m not accusing anyone of anything, but it does make me wonder…
>Peter Thomas has no stake in Wicket other than being a user, so comparing him to Ed Burns and Rod Johnson are off. Also, I haven’t seen such benchmarks from them, so my hunch is that it is your hunch, nothing more than that.
C’mon Eelco. Sure, Peter Thomas may have no direct affiliation to Wicket (committer, book author, etc.) but is clearly a Wicket lover. And that is fine! I’m all for promoting the framework that you love. Why wouldn’t you? It is such passion that leads to good articles and builds a community.
But, Peter, let’s be honest. If your experiment had led to Wicket finishing last in the performance, would you have posted this write-up on it? And Martijn have linked it on DZone with the title “Wicket dead last against Grails, Tapesty, and JSF/Seam”? Of course not!
I’m not accusing anyone of anything. I am the first to admit that if I take the time to write a post, it will probably be to promote Stripes. I don’t think there’s anything wrong with that, so let’s be honest about it.
I also want to make something else clear: by all means, do post about the framework you love. Wicket is top-notch and I’ve recommended it in a workplace where, yes, the situation, applications, developers, and needs made that Wicket was actually a better fit than Stripes. But, sadly, outside of the group of developers like us who are passionate, Wicket is not very well known. People know Struts and maybe JSF and that’s about it. So yes! Write-up about the advantages of Wicket, because if you don’t, who will? It’s not a Sun standard, and neither is Stripes.
Keep up the good work.
Cheers,
Frederic Daoud
http://www.stripesbook.com
@Frederic
Good question, yes, what if I came to the conclusion that there was something better than Wicket?
This may sound theatrical but the answer is I would seriously consider switching of course. Look up my previous blog posts, I used to be the biggest Spring MVC fan-boy but I switched to Wicket without much ado. I strongly believe in *not* getting too attached to any one technology even though one may have invested a couple of years or so in it.
Yeah, if there is a framework that would better suit me needs, I would consider it over Wicket as well, even though I did invest a lot of time in working on the framework, writing a book, participating in talks, etc. In the end, my whole involvement in Wicket stems from scratching my itch, which at the time was that I needed a framework that scales for development (larger teams, maintainable code, reuse in different contexts, etc). Last thing I want to be is a one trick pony. :-)
Great, that is an excellent attitude.
I just wish there were more people like you in the workplace. Instead, I get the “Struts is the de facto standard of Java web development.” *sigh*
Im with igor, tapestry is prepared to play with his components (grids, forms, the way that tapestry handle the data, etc..) so if you dont use it then you are wasting tapestry habilities and its really hard to be good on something when you cant use your advantages.
yes thomas is right about the documentation of tapestry one year ago when i start with tapestry it was so dificult to me to build the web app that i want, i had to use the request the session and sometimes it seems like a struts app, now i use more “tapestry code” and the performance is much better. i had never used wicket so i dont know if its better than tapestry, im just saying like Igor that this comparision is unfair….
@carlos
One of the primary objectives of this whole exercise is to do a performance comparison, not just implement a use case. That explains the focus on keeping the HTML pages and the processing that happens on each action identical. So the main thing here is performance, not lines of code, okay? If you find anything that gives any side an unfair advantage, let everyone know and I will certainly make the changes.
Now, if I had used Tapestry Grid and BeanDisplay components I’m sure that Igor and you would have started complaining that the benchmark is still biased because now Tapestry is producing more HTML or that using a “heavyweight” component gives Tapestry a disadvantage.
How about this, Wicket also has plenty of Grid components that integrate with Hibernate and also a Bean Form Generator, but I chose *not* to use these.
So please, stop the bogus arguments and answer the *real* questions, for example, can I integrate Hibernate Validator with Tapestry 5 or not or should I just give up?
Peter,
I’m not complaining at all. I just want to point out, that I feel like this comparison is not fair.
Rigth now there is no Hibernate Validator integration provided by Tapestry itself but there are third party libs providing the integration.
For example http://www.arsmachina.com.br/project/tapestrycrudhibernatevalidator.
Furthermore Tapestry has a wonderful validation mechanism. Why don’t you use it if you don’t know how to integrate Hibernate Validator?
Please tell me why is @NotNull better than @Validate(“required”)? I think it is really unfair to leave form validation unimplemented just because you prefer the Hibernate validation.
Is it lack of knowledge or intention to make Tapestry appear in a bad light?
What Peter is trying to do is to be conform with the Seam booking application, no matter the cost. Peter should be more flexible and try to experiment.
Need a validator that is not available in Tapestry? Just implement a http://tapestry.apache.org/tapestry5.1/apidocs/org/apache/tapestry5/Validator.html
If you need a client side validation you can extends Tapestry’s JavaScript class Tapestry. Validator like follows:
Tapestry.Validator = {
…
regexp : function(field, message, pattern)
{
var regexp = new RegExp(pattern);
field.addValidator(function(value)
{
if (! regexp.test(value)) throw message;
});
}
};
Just for the record, if there was a better server-side framework than Wicket, I would switch too. I also think GWT is a good fit for projects (either with or without Wicket) that need a lot more client-side interaction.
Pingback: “Perfbench” update: Tapestry 5 and Grails « Incremental Operations | Performance Struts And Suspension
@Igor
I did take a look at the Validator infrastructure, but I’ll try again. Even if I use the Tapestry built-in validation framework, getting it to work over Ajax (onblur) for each Form field will be very difficult. I agree, this is indeed to “conform” to the Seam app for the sake of the “ajax post cc number / name” rows in the performance test – but I really want to include more Ajax requests in the benchmark, to make it comprehensive.
I’m deeply suspicious of the Grails implementation, since the post login with 20 users apparently took 2.5 seconds. There’s some kind of locking (possibly at the DB?) which is slowing things down artificially. The fact that the “post confirm booking page” is so much faster is really telling.
If you ignore the post login, then the statement “Grails still has some way to go in terms of performance.” is false to fact. It’s right in line with Seam on all the counts.
It is granted that Tapestry and Wicket are faster—neither are as full-featured as Grails (as the comments above note), so I’d expect them to be faster.
@Robert Fisher: Would be great if you can go through the source and let me know where you think the implementation is not optimal.
Hi Peter,
Thanks for the write-up.
I think part of the reason for some debate here is that while this is a performance oriented posting, some of your “thoughts on tapestry5” notes cross into a subjective evaluation of the framework which are apart from the hard numbers. This is not to say your subjective evaluation is in error, just that going into it muddies the water of the performance evaluation.
I’d love to see a use-case oriented contest between the frameworks, with code submitted by a volunteer from each community. Conclusions would still be very subjective, but nevertheless it’s the right counterpart to have to your “implement the app as close to same way as possible in each framework” approach.
There are already so many framework comparisons out there, most of which I find highly debatable (and indeed I can see how parts of this post are debatable just as well).
The thing that sticks out for me here however is that, finally, a post ‘shows’ that so many of the posts that I read, particularly when they compare Wicket and Tapestry, are wrong in their assumption that Tapestry performs better and consumes less memory. I’ve read this many times, and I am sure that any of these authors made the assumption without measuring. As engineers measuring should always win from ‘common sense’, but alas, some of the loudest framework comparisons out there hardly even try to be objective. It’s nice to read a post – even though obviously from someone who is biased towards Wicket – with at least somewhat objective goals. And the source code is there for everyone to check and debate.
I love wicket too, but i have a problem because it use too much memory when is not needed .
please when you will make another comparisons do the stress test too …
i have one simple test for you :
try to load this page from examples on tomcat with xmx512M
wicket/-examples/repeater/?wicket:bookmarkablePage=:org.apache.wicket.examples.repeater.RepeatingPage
after 20k times it becomes too slow and with full memory
right now I try to learn tapestry because of wicket memory usage.
i did same stress test with tapestry tutorial application … and i don’t had issues at all , i tested over 200k times
@Dani – sounds very much like you have Wicket running in development mode
same issue in deployment mode, but seems to be the state-full problem .. it keeps all pages in memory until the session expires… so for performance we should use stateless components… I changed your application and removed all links from hotel list and I don’t had memory issue. so in wicket with attention we can keep low memory usage.
My test was not fair … but i have to read more about stateless :)
We have been using Wicket for our production system (www.teachscape.com) for years now, almost 100k users in total, though we probably don’t go over say a 1000 concurrently, we run it with 2GB VM, and never ever in those years did we have an out of memory error that was caused by Wicket. Runs for months at an end. So yes, make sure you’re not running in development mode, that you end sessions (otherwise your test is not representative), etc.
Pingback: Confluence: Tampere - Kuntalaisportaali
Pingback: Benchmarks Frameworks Web Java « Java Mania
It would be interesting to re-run your tests on Tapestry 5.2, which eliminates the page pool. You should see some significantly reduced use of the heap (but possibly some higher use of PermGen).
Tapestry has some configuration symbols such as
tapestry.page-pool.soft-limitandtapestry.page-pool.soft-waitwhich tell it if it should wait for an instance from the page pool to become available, or if it should go ahead and create a new instance.You might want to try and increase these values to see if they affect the spikes that appear in response times for 10+ users.
Otherwise, nice comparison. We recently created a reporting application using JasperReports, and it simply owned the previous version of the application in terms of performance which was build on Python / Django and used OFC for the charts.
Pingback: On Tapestry’s Performance « Tapestry 5 Blog - Thoughts on coding, technology and occasional stuff.
Nice bench.
did you have a look at http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/
Tapestry 5.2 and Play seems to be faster than others now.
@françois yes I saw that, IMO it can be dismissed as a “microbenchmark”. Come on, just one page and just rendering a list of objects!? I wouldn’t really use that to draw any useful conclusions about a *real* web application.
Funny to see people in the comments there still complaining that their favorite framework has been unfairly treated etc etc. :P
FWIW, he used the still-in-beta version of Wicket 1.5 which had a performance bug, see this comment.
Pingback: Confluence: Application Development Environments
Pingback: Confluence: Application Development Environments
Pingback: Confluence: Application Development Environments
Pingback: Load testing Seam-Booking with JMeter « Le Blog d'Akram Ben Aissi
Pingback: Confluence: Product Development and ongoing Projects
ambien and robaxin drug interactions price max
Floxin order overnight shipping
buy express Strattera
where to get lipothin in internet american express no rx
where can i buy medrol sleeping pills
Aricept buy with cod
Mobic cheap online
make money paid
meine arznei verschreiben Calan
buy synthroid without a prescriptin online
Cytotec pharmacie faire livrer
liefern Mobic apotheke sie
buy Metformin 500 mg with cheapest price
buy discount keppra without prescription
effect lioresal diners club saturday shipping south carolina
money making surveys uk
metformin without prescription
buy brand lipothin pharmaceutical free shipping
Micardis 20 mg sr purchase
money from answering surveys
best paid online surveys uk
cheapest online letrozole
Medrol no doctors consult at MN
muscle relaxant 25mg lioresal 30mg price werking
purchase aricept without a prescription
survey check
Major route of metabolism of misoprostol
legit online surveys
Valtrex ems
coupon codes glucophage shop switching otc
ontario price lipothin vitamin c therapy weight loss sales indoco
Augmentin avere per meno
Floxin with no perscription and delivered over night
buy cod selegiline no prescription
i want lipothin in internet moneygram no rx thailand
stromectol 3mg anthelmintic knee pain treatment
zithromax no prescription overnight shipping
buy Dramamine cr online
Micardis commander pas
where to buy Strattera 25 mg no prescription
Pingback: Confluence: Skiline