Tom,

I totally agree - its all in how the server gen's the code, for the most
part. The rest is related to the spec itself and how much it allows app
servers to optimize. There was a discussion about the thread safety of
JSP tags a little while ago. Here is what I wrote up:

http://www.mail-archive.com/[email protected]/msg39324.html

The reason I bring this email up, is that I have listed a section from
the JSP spec where they discuss that a JSP tag should remain dedicated
to the page:

"The JSP page implementation class instantiates a tag handler object, or
reuses an existing tag handler object, for each action in the JSP page."

This means that app servers *could* start pooling these tags to reduce
the overall creation and garbage collection. I'd be interested in
someone who would benchmark the differences using something that is open
source (like Jasper), which could be quickly modified to use Doug Lea's
object pooling or something similar and compared.

James

> -----Original Message-----
> From: Lister, Tom (ANTS) [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, September 26, 2002 7:22 AM
> To: 'Struts Users Mailing List'
> Subject: RE: Struts and high performance sites revisited
> 
> 
> Hi
> I've recently been struggling with performance issues related 
> to tags, especially where there are large number in some of 
> our pages. The biggest improvment we got was by switching 
> application servers. Specifically by upgrading to the latest 
> Tomcat 4.1.11. The difference in response is incredible. So 
> it would seem that the major issue is with the type of code 
> generated by the servlet engine. We spent some time looking 
> at the generated code, the major issue being that every tag 
> reference is created as a new object. There must be better 
> way to do this. Until this point I was wrongly assuming that 
> the tags were run as just method calls on one instance. will 
> JSTL improve on this ?
> 
> :-)
> Tom Lister
> * 020 7612 3030
> * [EMAIL PROTECTED]
> 
> 
> -----Original Message-----
> From: David Zimmerman [mailto:[EMAIL PROTECTED]]
> Sent: 26 September 2002 10:43
> To: [EMAIL PROTECTED]
> Subject: Struts and high performance sites revisited
> 
> 
> Ok, so we got it nailed down these statements...
> 
> - The Struts Controller doesn't add more overhead than a high 
> performance site should be able to handle. In the regard 
> flexibility contra performance, using the controller makes 
> your application manageable with negligible overhead.
> 
> - There was also the everlasting discussion on EJB's be or 
> not to be. I think that there are loads of variables that 
> affects the choices of the design and that there still 
> remains some issues with EJB's. However when only using 
> stateless session beans with DAO's I think that the 
> scalability-flexability-performance goes hand in hand and 
> makes a preferrable design choice. Anyone disagrees? Would be 
> nice to hear your opinions.
> 
> - But what was not discussed was the overhead of custom tags. 
> This seems to be a question much avoided everywhere. When 
> talking about flexability. Oh yes, use them. They makes your 
> pages much easier to build and manage. They also makes for a 
> great design of the application. BUT (capital letters), what 
> about the performance overhead of the tags? When designing a 
> web site where the absolute focus is to be able to handle as 
> many transactions as possible to a low cost. Doesn't custom 
> tags become very expensive to use in a case like this? There 
> must have been extensive testing made on this. Does anyone 
> have any facts or thoughts on this?
> 
> 
> 
> 
> ____________________________________________________________
> Tired of all the SPAM in your inbox? Switch to LYCOS MAIL 
> PLUS http://www.mail.lycos.com/brandPage.shtml?pageId=plus
> 
> --
> To unsubscribe, e-mail: 
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> **************************************************************
> *************
> This communication (including any attachments) contains 
> confidential information.  If you are not the intended 
> recipient and you have received this communication in error, 
> you should destroy it without copying, disclosing or 
> otherwise using its contents.  Please notify the sender 
> immediately of the error.
> 
> Internet communications are not necessarily secure and may be 
> intercepted or changed after they are sent.  Abbey National 
> Treasury Services plc does not accept liability for any loss 
> you may suffer as a result of interception or any liability 
> for such changes.  If you wish to confirm the origin or 
> content of this communication, please contact the sender by 
> using an alternative means of communication.
> 
> This communication does not create or modify any contract 
> and, unless otherwise stated, is not intended to be 
> contractually binding.
> 
> Abbey National Treasury Services plc. Registered Office:  
> Abbey National House, 2 Triton Square, Regents Place, London 
> NW1 3AN.  Registered in England under Company Registration 
> Number: 2338548.  Regulated by the Financial Services Authority (FSA).
> **************************************************************
> *************
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to