Hi,
Thanks for the information. So are you firing off
the requests manually,
simply by hitting the send key simultaneously on
three browsers?
Yes, you are right :-)
If four transformations run concurrently, with no
contention between them,
then you would expect each one to take four times as
long as when the
processor is dedicated to a single user. This seems
to be consistent with
the results you observe.
Does this mean that all the four requests are being
processed by a single processor. Are the XSLT
processors internally single threaded ?
If not then why should T*N come into picture when we
have a huge UNIX box and only 4 testers are using the
application now.
Achieving optimal response time then
depends on scheduling the work intelligently to
avoid overloading the
available memory, which depends on how you configure
your application
server. The ideal concurrency in this environment is
probably obtained by
taking the available memory, subtracting the shared
memory requirement, and
dividing what's left by the memory requirement of
each transformation.
Let me play around with the JVM / Heap size /
Websphere setting a bit and I will publish the results
to the group again.
Thanks,
Bhupendra.
--- Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
Thanks for the information. So are you firing off
the requests manually,
simply by hitting the send key simultaneously on
three browsers?
If four transformations run concurrently, with no
contention between them,
then you would expect each one to take four times as
long as when the
processor is dedicated to a single user. This seems
to be consistent with
the results you observe.
In a real environment the arrival time of requests
will be randomly
distributed, and there will be significant think
time, so the response time
will be much better than T*N where T is the
transformation time and N is the
number of users.
As the number of users increases you have a classic
transaction processing
scenario. The theoretical maximum throughput you can
achieve
(transformations per second) is determined by
dividing the machine capacity
by the cost of each transformation. Achieving
optimal response time then
depends on scheduling the work intelligently to
avoid overloading the
available memory, which depends on how you configure
your application
server. The ideal concurrency in this environment is
probably obtained by
taking the available memory, subtracting the shared
memory requirement, and
dividing what's left by the memory requirement of
each transformation. Don't
ask me to translate this into concrete Websphere
terms!
Michael Kay
-----Original Message-----
From: Bhupendra Singh
[mailto:skbhupendra(_at_)yahoo(_dot_)co(_dot_)uk]
Sent: 01 December 2004 18:18
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] Performance with multiple users
during
transformation
Michael ,
Thanks for the input, Heres what you requested
for.
You need to explain your measurement scenario
more
carefully. How is the
XSLT processor running - as a servlet?
The XSLT processor is running as a servlet. Its a
Web
based application, which takes client request with
Servlets. The serlvet brings the data in XML
format
and then uses the transformer to make another XML,
which is send back to the user.
How are you
measuring response time?
I am taking the diference of the time before and
after
the Transformer.transform() method and printing it
in
a log file.
Are
these transformations all
using the same stylesheet?
All the users are requesting the same page with
the
same parameter, so the same input XML and
stylesheet
is used.
Are you saving the
compiled stylesheet in memory?
I am storing the compiled XSLT as templates in a
Hashmap. I use this Template to create a new
Transformer object using the
templates.newTransformer().
Before taking the test I am running a dummy user
request to build this template in the Hashmap.
Are they all running in the same thread, or do
you
have a pool of
threads/processes?
Each user fires the request from different IE
sessions. Thus the servlet threads will be
different
for each.
how much memory you
are allocating to the Java VM,
I have kept the minimum JVM heap size to 1 GB for
Websphere App server.
--- Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
I have a 250 KB XML to be transformed into
another
XMl
document. I am using a high end UNIX box with
8
CPUs
and 32 Gig RAM.
Intially I was using Xalan and the timings for
transformation are as follows:
1 user : 3 secs
2 users: 6 secs
4 users: 8 secs
Then I changed to Saxon8 and the timings are
1 user : 1.5 secs
2 users: 3 secs
4 users: 4 secs
(I fear whats going to happen when 1000 users
will
use
the applicaiton)
You need to explain your measurement scenario
more
carefully. How is the
XSLT processor running - as a servlet? How are
you
measuring response time?
What is the think time between transactions? Are
these transformations all
using the same stylesheet? Are you saving the
compiled stylesheet in memory?
Are they all running in the same thread, or do
you
have a pool of
threads/processes?
Although I got a 50% performance enhancement
with
Saxon for each scenario, but I still dont
understand
one thing why do we have the increase in
transformation timing as the users increase.
That depends very much on how the work is being
scheduled, which is why I
asked about your execution environment.
Since Saxon is based on SAX parsing there
should
be no
memory constrained (Also my 32 Gig RAM is
never
utilised more than 5GB at any time.)
No, that's a bad misunderstanding. Every XSLT
processor today builds the
source document in memory. However, 250Kb is not
particularly big. Again,
however, it depends on how you are scheduling
the
work, how much memory you
are allocating to the Java VM, and so on.
Can somebody briefly tell me how the
transformation
works, starting from how the XSL is parserd,
how
the
XML is parsed and then the transformation.
Can the parser and the XSLT processors be
different.
If you're using Saxon, then the article at
http://www.xml.com/pub/r/1065 may
be helpful.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive:
=== message truncated ===
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--