IMHO a sensible strategy of developping apps is to first focus on the behavoir and after that focus on performance issues. That does not mean that it is wrong to take performance issues in account in an early stage, but just do not let it overtake the main focus of your project.
In my experience caching CAN make a huge difference though, especially when you have database heavy apps or - like Jeff said - object that have high initialisation costs. But ya, things like synchronisation can be killers as well. And if you use transactions for instance... be smart with them (like: is it possible to do more in the same transaction... made huge differences for us when working with OJB). And as a side note: three years ago I developed several java webapps for the AS-400 platform (JDK1.1.x). In that case object creation *was* very expensive so it did make sense to use object caching. I do not know about the current performance charactaristics of that platform. Second side note: GC can give you problems at times. A recent project where we made heavy use of JSTL could crash our server! There is/ are memory leak(s) in JSTL presumably the forEach tag. The strange thing was that in certain cases when the GC did a run the JVM ended up using more memory than before this run. On several servers (both on Win and Lunix) the memory usage could exeed gigabytes within one minute before crashing... That brings me to an example where caching makes a big difference. If you look at the performance gain Tomcat 4.1.x got compared to Tomcat 4.0.x: for our apps it was the caching of the custom tags in Tomcat 4.1.x that made the difference (about 1500 milis!). Funny thing though is that, allthough Tomcat 4.0.x is a lot slower with our JSTL intensive project than Tomcat 4.1.x, the former never crashes. This is to illustrate that, allthough caching can make a huge difference at times, it also adds complexity thus usually more bugs (can confirm that from personal experience too!) So my bottom line is to be practical. First build your app only addressing the most obvious performance issues. When all works/ is stable look at performance characteristics. IF you want to cache be aware of the added complexity, maybe using something like JCS (http://jakarta.apache.org/turbine/jcs/index.html) can help reducing that (allthough I never used it). The reason that I sometimes use singleton controllers is that those controllers do a lot of initialisation that is equal for all users and should be done only once. Eelco -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Schnitzer, Jeff Sent: maandag 31 maart 2003 23:42 To: [EMAIL PROTECTED] Subject: RE: [Mav-user] reusable controllers and session objects > From: Valeri Sarantchouk [mailto:[EMAIL PROTECTED] > > I am trying to avoid creating new objects at every request. > Is it possible to use a servlet as a (Trhowaway2) > Controller? Or other reusable accross requests conroller. > > [...] > > ClientModel has 38 fields and its creation and rendering > are costly operations. Plus we have at least 70 concurrent > users (accessing the same view at the same time) at low > periods and 350+ at high, so creating new objects for each > request and passing old ones to gc doesn't look good from > performace point of view. > > In "old" application, I use an object pool to get instances > of Client objects for new users; and re-use Client objects > found in user's session for logged-in users. > > Can you advise me on how to replicate an object pool with > Maverick and how to reuse the same object found in session? I see you found the ControllerSingleton (and presumably FormBeanUser) controller base classes. However, are you sure of the performance characteristics of your application? Much research has gone into this subject, and the general conclusion has been that the performance cost of object creation and collection is vastly less than the performance cost of synchronization. The generational garbage collection scheme in modern JVMs is very efficient, especially with short-lived objects such as Throwaway controllers. On the other hand, the thread synchronization required for an object pool is tortuous for an application with high concurrency. Search the JBoss list for this subject - they concluded that the object pooling of EJBs is only of value when the initialization cost of a bean is very high (establishing network connections, etc). My own experience confirms this. The Sims Online player website produces zillions of objects (much, much more than a typical website) yet when maxed out under load testing I find that threads are always waiting for monitor locks. Just to give you some more idea of relative scale, a single Tomcat request produces a flurry of objects. Populating bean properties with BeanUtils produces a flurry of objects. Every JDBC driver I've ever seen produces *vast* quantities of garbage. Watching an application under a profiler is an enlightening experience - you'll be amazed at how many char[] and String objects a running Java app produces. A minimal Maverick invocation produces 3 or 4 short-lived objects (including String manipulation). This is like shouting into a jet engine - nobody is going to hear it on the other side. Jeff Schnitzer [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ [INVALID FOOTER] ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ [INVALID FOOTER]
