Re: Struts and high performance sites revisited
On Thu, 26 Sep 2002, David Zimmerman wrote: Date: Thu, 26 Sep 2002 10:42:34 +0100 From: David Zimmerman [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] 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. That's a pretty good summary. For the vast majority of Struts based applications, the overhead of the Struts controller servlet is down in the noise level percentages -- and, of course, if you were to consider replacing it, you'd have to add back in the overhead of your replacement solution anyway. - 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. There is no one correct answer to this question. Anyone trying to answer it with an absolute always use EJBs or never use EJBs should not be considered a trustworthy source of advice. What you *should* always start with is an understanding of your application's functional requirements -- both initially, and the directions it is likely to go. Just as a silly example, if you're building a simple intranet app for a ten-person department, with a database content measured in kilobytes instead of megabytes, you should just pick the technology you are the most familiar with and be done with it -- even if your solution isn't fastest possible, spending a couple of hundred dollars more on your server hardware is ***much*** cheaper than paying for the extra hours of development to learn a new technology. However, if your development team knows the stateless session bean + DAOs design pattern already, there's nothing wrong with using it. - 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? Here are two basic lines of thoughts to consider. As with concern over the controller servlet's overhead, you can't just say custom tags are expensive so do not use them, without considering the cost of whatever you are going to replace them with. This matters a lot more than the controller servlet's potential overhead in many cases, but my experience is that the database tier tends to dominate the overall performance overhead of a web app, no matter what technology you use for the presentation tier. Second, the performance overhead of custom tags is very much dependent upon the quality of the JSP page compiler you are using, so it is (as with most things) impossible to create absolute guidelines that cover every possible situation. As an example, you should try running the same Struts based app on the current releases of Tomcat 4.0 (with the original JSP page compiler) and Tomcat 4.1 (with the completely rewritten Jasper 2 page compiler that has many optimizations to improve the generated code for custom tags). Performance improvements on the order of 600% to 800% have been observed on pages with lots of custom tags (which is typical of Struts apps), with *zero* changes to the application itself. You will see a very wide range of performance when you try out various other app servers as well. The moral of the story -- it's not custom tags that are fast or slow, it is the JSP page compiler's generated code for those tags that is fast or slow. Without defining what app server (and version) you are talking about, trying to ask about the performance of custom tags is a meaningless question. Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts and high performance sites revisited
On Thu, 26 Sep 2002, Lister, Tom (ANTS) wrote: Date: Thu, 26 Sep 2002 13:21:45 +0100 From: Lister, Tom (ANTS) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] 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. The JSP Specification provides many standard opportunities that a JSP page compiler can use to improve the quality of the generated code for a custom tag invocation. One of the simplest is to reuse tag instances (as the Jasper 2 compiler in Tomcat 4.1 can do), but there are more aggressive things you can do as well. Consider something like this: c:forEach ... something that loops 100 times ... foo:bar name=x value=y/ /c:forEach Not only is it legal to reuse the custom tag instance for the bar tag (instead of creating 100 instances the way Tomcat 4.0 does), but the page compiler need not even call the setName() and setValue() methods 100 times inside the loop -- these can be moved outside the loop using standard techniques that optimizing compilers have used for decades. The JSP page compiler in Tomcat 4.1 and 5.0 (called Jasper 2) was rewritten from the ground up, primarily in order to make optimizations like this possible. You are seeing the fruits of this effort in 4.1, but we are by no means done with improving the optimizations that the page compiler can perform. will JSTL improve on this ? JSTL by itself doesn't change the code that is generated for a custom tag -- that's up to the page compiler. But the page compiler does have the opportunity to recognize JSTL tags (since they are a standard now) and generate specially optimized code (for example, turning a c:forEach into a real Java for statement instead of a custom tag invocation), as long as the semantic requirements are met. So, once the page compilers have been improved in this manner, using c:forEach will definitely run faster than a Struts logic:iterate tag that iterates the same number of times (unless someone were to optimize their page compiler for Struts tags, which seems less likely than optimizing for JSTL :-). :-) Tom Lister * 020 7612 3030 * [EMAIL PROTECTED] Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts and high performance sites revisited
a. Stateless session beans are fine until you need transactional boundaries to protect data integrity. If you want to improve performance of the app, design a persistent cache for immutable data (or data that rarely changes) to reduce trips to the data store. b. There is no overhead for custom tags except for the initial compilation of the JSP into an object. The only exception here is, obviously, you inundate a JSP with tags. Then you will get the same performance hit you get when having a class method with a poorly-design looping or conditional algorithm. Design, design, design. You skip or shortchange the design phase (should be at least 30 percent of your project), you get what you deserve. -Original Message- From: David Zimmerman [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 5:43 AM 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:[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]
RE: Struts and high performance sites revisited
You skip or shortchange the design phase (should be at least 30 percent of your project), you get what you deserve. Amen my brotha'! Preach on! robert -Original Message- From: David Zimmerman [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 5:43 AM 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:[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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:[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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts and high performance sites revisited
I've always wondered the same. I haven't found a definitive answer, but there's a lot of good info referenced in an old posting from Ted Husted: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14397.html Paul -Original Message- From: David Zimmerman [mailto:[EMAIL PROTECTED]] Sent: September 26, 2002 5:43 AM 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:[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]
RE: Struts and high performance sites revisited
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/struts-user@jakarta.apache.org/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
