"Wicket performance" is not in the LITERAL SENSE. Since wicket is one of the layers and the farthest client facing layer, usually all the layers down the line are connect through it. So I was suggesting overall how "application performance/page loading/page response time" can be improved, not necessarily saying wicket needs to improve something.
As about Terracotta wicket plugin, performance can be improved by using that as part of the distributed application to improve performance - again for the application in general and hence the user experience. Matej Knopp-2 wrote: > > Hi, > >> Yes - overall I do think Wicket is a great framework. I believe there is >> a >> lot of tuning at various levels you can do with wicket to improve the >> performance. e.g. using >> Terracotta wicket plugin, > how exactly is this supposed to help wicket performance? >> using cache server in the middle for model rather than hitting db > not really related to wicket >> caching markups, resources > wicket markup is cached, so are certain resources (for which it makes > sense) >> sending zipped and comment/space removed js and stylesheets and so on. > we already do that > > There is whole bunch of things you can do, best of all the code is > excellent, with >> good comments and quality, which makes it easy to understand the >> internals >> and tune it to your needs. Personally I havent seen better code than this >> for open source projects. > > Thanks. There sure is a lot of to improve, but performance-wise, in my > experience, the model/database layer usually is the bottleneck. And > it's very often because of not using detachable models properly. Some > users have very rich model and when wicket serializes that the > serialized data can have couple of tens of megabytes. It is very bad > practice to hold such data in session and that's where detachable > models can help a lot. > > -Matej > >> HTH >> >> >> >> ccgroup wrote: >>> >>> Thank you for the response. I have profiled the application using >>> YourKit >>> and I am still working on optimizing the application. Your work and >>> response was helpful, and I have already identified and resolved >>> multiple >>> stateful pages using Detachable models. Some pages take up to 3 seconds >>> to render, which I think is a serialization issue, but I am optimistic >>> that the issue is the NOOB factor and not wicket. Overall I am really >>> excited to be out of the Struts,Webflow and SpringMVC world and into the >>> component world. >>> >>> Do you feel that you get as good or better performance with wicket as >>> you >>> have with other web frameworks. I am trying to find the point of >>> diminishing returns with regards to performance. >>> >>> Thanks again. >>> Tim Christensen >>> >>> >>> Ritesh Trivedi wrote: >>>> >>>> Sort of. I had to increase the heap size, optimize caching and remove >>>> memory leaks - had to run profiler etc and had to run Wicket app in >>>> debug >>>> mode, all this will help you understand your app and framework better. >>>> Refresh time has improved dramatically, but initial load time is still >>>> high on my dev machine, but that is due to the rest of the framework >>>> needing first time initialization. >>>> >>>> Let me throw one more piece of advice to the community... >>>> >>>> I had a memory leak and still probably do, havent gotten time to >>>> completely eradicate the problem. The root of the problem is - and >>>> beginners dont realize this off the bat when starting wicket >>>> development, >>>> but is very very important, I believe should be stressed at a very >>>> visible location - you should know the difference between statefull and >>>> stateless pages. Statefull pages store the page instance in the session >>>> and can cause massive leak if the session duration is too long. The >>>> problem magnifies 100x if you have public/SEO friendly areas of the >>>> site >>>> which are accidently statefull since the crawler activity will create >>>> too >>>> many sessions and your memory usage will grow dramatically. And it isnt >>>> a >>>> piece of cake to make all the functionality on your page stateless >>>> especially if the page is good size/moderate complexity and has various >>>> different components. If you search the list, you will see someone else >>>> also had exact same issue. >>>> >>>> I have to revisit this in very near future to do a clean sweep. >>>> >>>> >>>> ccgroup wrote: >>>>> >>>>> Did you ever determine the cause? I am having a similar problem, it >>>>> is >>>>> not acceptable. >>>>> >>>>> >>>>> >>>>> Ritesh Trivedi wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have created first couple of pages of my wicket application but >>>>>> have >>>>>> some performance concerns. >>>>>> >>>>>> The pages (even the refresh alone takes 6-7 secs on Dual Core 2.2GHz >>>>>> Pentium with 4GB of RAM). DB is located on the remote host, but has >>>>>> caching at the application server - so thats not adding to the >>>>>> latency >>>>>> for the refresh. Here is the requestlogger information for the home >>>>>> page refresh couple of times >>>>>> >>>>>> Can someone point me to the direction on going about finding out what >>>>>> is taking this long other than (and may be simpler than) running a >>>>>> profiler on the application - atleast initially. >>>>>> >>>>>> My application is running in deployment mode and is running in >>>>>> tomcat. >>>>>> >>>>>> ===== >>>>>> >>>>>> !!!!!!!!!!!!!!!!! before getting top nav menuitems 1208209856242 >>>>>> !!!!!!!!!!!!!!!!! after getting top nav menuitems 1208209860972 time >>>>>> taken 4730 >>>>>> 2008-04-14 14:51:07,677 (http-0.0.0.0-8080-Processor12) [ >>>>>> RequestLogger.jav >>>>>> a:320:INFO ] >>>>>> time=11567,event=BookmarkablePage[com.neobits.web.pages.Index],resp >>>>>> onse=BookmarkablePage[com.neobits.web.pages.Index],sessionid=729B1C0D58665D15518 >>>>>> 044E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 >>>>>> PDT 2008,re >>>>>> quests=4,totaltime=28472,activerequests=3,maxmem=532M,total=266M,used=56M >>>>>> >>>>>> !!!!!!!!!!!!!!!!! before getting top nav menuitems 1208209878458 >>>>>> !!!!!!!!!!!!!!!!! after getting top nav menuitems 1208209878696 time >>>>>> taken 238 >>>>>> 2008-04-14 14:51:25,266 (http-0.0.0.0-8080-Processor4) [ >>>>>> RequestLogger.java >>>>>> :320:INFO ] >>>>>> time=6888,event=BookmarkablePage[com.neobits.web.pages.Index],respon >>>>>> se=BookmarkablePage[com.neobits.web.pages.Index],sessionid=729B1C0D58665D1551804 >>>>>> 4E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 >>>>>> PDT >>>>>> 2008,requ >>>>>> ests=5,totaltime=35360,activerequests=3,maxmem=532M,total=266M,used=55M >>>>>> >>>>>> !!!!!!!!!!!!!!!!! before getting top nav menuitems 1208209893292 >>>>>> !!!!!!!!!!!!!!!!! after getting top nav menuitems 1208209893526 time >>>>>> taken 234 >>>>>> 2008-04-14 14:51:40,514 (http-0.0.0.0-8080-Processor6) [ >>>>>> RequestLogger.java >>>>>> :320:INFO ] >>>>>> time=7309,event=BookmarkablePage[com.neobits.web.pages.Index],respon >>>>>> se=BookmarkablePage[com.neobits.web.pages.Index],sessionid=729B1C0D58665D1551804 >>>>>> 4E5C8A63088.jvm1,sessionsize=1177,sessionstart=Mon Apr 14 14:38:51 >>>>>> PDT >>>>>> 2008,requ >>>>>> ests=6,totaltime=42669,activerequests=4,maxmem=532M,total=266M,used=46M >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Performance-question-tp16690935p21645478.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Performance-question-tp16690935p21645994.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
