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, using cache server in the
middle for model rather than hitting db, caching markups, resources, sending
zipped and comment/space removed js and stylesheets and so on. 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.

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

Reply via email to