On Fri, 5 Sep 2003, tum curtin wrote:
> Date: Fri, 05 Sep 2003 08:59:01 -0400
> From: tum curtin <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: TMC Petshop, java performance tuning, struts
>
> I have recently read the results paper from the
> second benchmark test run by The Middleware
> Company (TMC) comparing the performance of the
> Petshop application using Java solution
> and .NET solutions.
>
> (http://www.middleware-company.com/casestudy/tmc-performance-study-jul-2003.pdf)
> This paper would be very useful I believe
> to anyone who is interested in fine tuning the
> performance of their application and server.
>
> IMO the results paper seems to suggest that Java
> solutions can be just as fast as .NET solutions
> but that some Java solutions can be much much worse.
> In particular, a java solution using struts is
> unlikely to perform as well as a solution that does
> not use some form of introspection (as struts does to
> populate beans from forms). I have several questions
> regarding these conclusions.
>
> 1. Are they accurate based on the evidence presented
> in the study
>
I would presume they are accurately measured (have no way to verify), but
the key to understanding this test is the description of the testing
scenario. They spent a LOT of time tuning things so that the database and
network were not bottlenecks; the goal being to measure the CPU time in
the middle tier. While that's interesting, how often is it relevant in
the real world, where database and network latencies are the normal
bottlenecks to response time?
> 2. Does anyone know the identities of the two java
> servers used in the study
>
Anybody who authoritatively answers that question is in big time trouble
because it would break NDA agreements :-).
> 3. In using struts does the productivity gains outway
> the performance cost and can this performance cost
> be adequately mitigated by upgrading hardware.
>
For the first part of this question, you need to determine if it even
matters in your particular app. For the second part, it's mitigated by
adding more/faster CPUs.
> 4. Have any similar tests been run in which the Java
> servers are run on Unix platforms instead of
> Windows Server 2003.
>
I did some microbenchmarks on the commons-beanutils code that is in turn
used by Struts -- see the message archives for the
[EMAIL PROTECTED] mailing list and search for
"microbenchmarks". A couple of things my tests showed were pretty
interesting:
* When using BeanUtils.copyProperties() or PropertyUtils.copyProperties(),
using a DynaActionForm (which uses a HashMap but no reflection) is
actually faster than using standard ActionForm beans.
* The BeanUtils.populate() method -- which is expressly tuned to deal
with copying request attributes into your form bean -- is substantially
faster than BeanUtils.copyProperties() is.
* As expected, recent JVMs are substantially faster than earlier ones
at reflection-based processing.
> 5. Has anyone performing tests on their own struts
> apps found similar results concerning the high
> costs of the introspection process.
>
It can only possibly matter if CPU time on your middle tier server (the
one running your webapps) is your response time bottleneck. Is it for
you? If so, then this matters. If not, then it probably doesn't.
IMHO, the most important single issue for performance of Struts based apps
is the quality of your JSP page compiler. Just as an example, the Tomcat
admin app is Struts based, and the difference between running it against
an early 4.0.x version versus current 4.1.x or 5.0.x versions is night and
day -- six times to eight times faster, and visibly more responsive even
in a single user environment. If you're looking for performance
improvements, in general you should focus on:
* JDK you're running
* JSP page compiler
* Servlet container you're running
* Database tuning
* Network tuning
before getting to the minutiae of CPU time comparisons for things like
reflection.
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
