Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Message-ID: <002e01c2c14b$1b14ef60$8e00a8c0@pegasusii>
From: "Attila Szegedi" <szegedia@freemail.hu>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
References: <001301c2c146$fb0c8b50$0100a8c0@vikram>
Subject: Re: Justifying Tag Libraries - Slightly long
Date: Tue, 21 Jan 2003 13:46:23 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Profiling usually shows that pretty much of the overhead of a dynamically
generated page is usually associated with char-to-byte conversion (which
naturally doesn't occur when serving a static page). This is not related to
taglibs actually, but hits any technology that takes characters on input and
produces bytes on output (a HTTP response is ultimately a sequence of
bytes) - JSP, template engines, whatnot.

If you can pre-generate pages (i.e. they don't really have dynamic content,
but are just localized versions), do so. Either as part of the build
process, or on server startup. A nice technique for generating a page only
once on demand is to insert a caching filter into the webapp - that way, a
page will get rendered dynamically only once, and thereafter served from
cache until the time you specify in its Expires HTTP header passes (if the
pages rarely change, you can set it to expire, say, in next 24 hours). If
only parts of the page are cacheable, you can use OpenSymphony's OSCache to
cache only portions of the page.

Another thing that can cause big slowdowns in JSP pages utilizing many tags
is the (IMHO) horribly flawed design of BodyTag-s. The JSP spec mandates
that a body of a tag - written into an internal BodyContent writer - be
buffered, then the buffered content retrieved (say, in doAfterBody) and
processed. With many nested tags, you get lots of buffering and
(more-or-less) copying to the outer writer in a waterfall-alike manner. A
much better design would have been (again, IMHO) to simply chain writers - a
body tag gets a reference to the currently effective Writer, wraps it into
another Writer that implements the transforming logic, then returns the new
writer and the JSP runtime makes that the current writer. That way, nested
body tags would create layers of writers - a write() on the writer of the
innermost tag wold propagate to the outermost, transforming content along
the way. Buffering would no longer be mandatory (altough still possible if
the transformation algorithm calls for it - a Writer implementation could
just buffer as much input as required to produce a chunk of output).

In summary, consider server-side content caching.

--
Attila Szegedi
home: http://www.szegedi.org

----- Original Message -----
From: "Vikram Goyal" <tech@craftbits.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Sent: 2003. janu�r 21. 5:09
Subject: Justifying Tag Libraries - Slightly long


Hi all,

After failing to convince my boss otherwise about his fear of slowing down
the performance of an internationalizated web application by the use of
Struts tags, I decided to set up a stress test environment to prove that
tags do not have that high a performance issue. However, much to my dismay
and surprise, I found that my boss was correct! Tags, do indeed, affect
performance, and we are not talking about nanoseconds of difference. Here is
my test environement and how I went about doing so:

Single Client Machine: Windows XP Pro - with 512 MB RAM, Pentium 4 (1.7Mhz),
IE 5.5.
Server: Windows XP Pro running Weblogic 7.1 with 512 MB RAM, Pentium 4 (1.7
Mhz)

Stress Test Tool: Microsoft Web Application Stress Tool

Struts Version: Struts 1.1b2.

Testing method:
1. Ran 1000 threads on a simple JSP page, which used bean tags to render the
content of the page. This is a simple page, which contains a lot of text,
all of which is read from ApplicationResources.  This page was ideal for the
test as it had the most tags (40+).
2. Ran 1000 threads on the same page. However, this page, is static,
meaning, that the page accessed was pre generated using an internationlation
mechanism that simply generates static html pages for different languages
and puts them in respective i18ned directories. So a user who understands
spanish would go to the document root for spanish and so on.

Well, the results:
Without boring you with all the figures, let me just put get into the result
analysis.
Overall, I found that for the first case, the difference between the time
taken to get the first byte(ttfb) of the page and time taken to get the last
byte(ttlb) of the page, was vast. In the second case, this difference was
miniscual. This meant, that in the first case, the pages were received
faster, but took longer to finish downloading. In the second case, the pages
took slightly longer to come through, but finished downloading much much
faster than the first case (150 times faster than first case).

I ran the tests three times for 25, 100 and 1000 clients and all the tests
results gave the same analysis.

With these figures in hand, I had no answer to my boss's snide remarks about
uh, hmm ... well never mind, except to say that I had no answer.  What I am
hoping from the list is if someone can help me understand why this would
happen, would this be as expected and well, how do you still justify the
usage of tags.

Best Regards,
Vikram Goyal


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>