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