Yes, sometimes I loose balance between adhering to initial 
design and making shortcuts when I encounter a performance
bottleneck.

I also considered contrast of JSTL simplicity from page
author point of view with its complexity from 
precompiler/VM point of view, and concluded (but I still could be wrong) that even 
JSF+JSTL don't make JSP ideal 
View technology. I see XSLT as the cleanest and most 
elegant approach to build a View. Though, I like XMLC and
Velocity for their performance. 

(I might look unreasonably obsessed with performance
issues. I am :) I think that each new software
product I develop should perform at least on the same level
as its predecessor. Expecially knowing how good PHP- and
Perl-based solutions could be in simple applications.)

Thanks,

Valeri

---


On Tue, 1 Apr 2003 10:41:51   
 Eelco Hillenius wrote:
>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]
>


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus


-------------------------------------------------------
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]

Reply via email to