Supun Kamburugamuva wrote:
I think I have found the reason behind Guththila's low performance on
large data sets. Guththila's token cache gets too big in large
requests. A simple release statement was missing in the code and that
causes the cache to get too big. I need to investigate further on this
and want to run the performance tests again.
It is good news that you have figured the reason for large data set
problem. I think it is critical that we uplift performance for large
data sets as well. Could you please point me to the source file location
where you found the problem so that I too could have a look.
On another related note, I am really keen on seeing how vtd-xml would
perform. I wish I had more time to write a parser wrapper with vtd-xml :)
And another thing is to try with some async transport and see how it
works out for us. This is based on the fact that the secret of Synapse
performance is based on NIO based Axis2 transport. However, I am not
sure how this would turn out for us.
And of course, FCGI module with httpd would be an exciting option as well.
Thanks,
Samisa...
Regards,
Supun..
On Mon, May 12, 2008 at 12:20 PM, Supun Kamburugamuva
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Yes I agree with Nabeel. We need to figure out why our performance
is low when the data sizes are large. At the surface level it
seems that it has nothing to do with the Axis2/C engine when
compare to the Axis2 Java. Also when the data sizes are large
httpd itself may get slow.
Another important thing is we need to see why guththila is slow
when it comes to large data sizes. My guess is the buffer
mechanism used in the guththila_xml_parser is causing this. But
need to investigate this properly using a profiling tool.
Thanks,
Supun..
On Sun, May 11, 2008 at 9:03 PM, Nabeel Yoosuf
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
It's encouraging to see the C implementation performs well.
As per the graphs, the performance gap between the two
implementations implementations (Java/C) and between the two
parsers (Guththila/Libxml2) narrows down as the data set size
increases. There could possibly be two reasons for this.
1. Increased bandwidth utilization (as indicated in one of
those graphs) adds more network latency.
2. The engine is less efficient in processing large data sets
compared to small sets.
It would be interesting to see which of the above two is the
dominant factor.
If it is the first one, one approach may be to introduce
message compression techniques for large data sets further
improve performance. If it is the second one, one possible
direction is to see if the same data set is repeatedly
processed and take preventive actions (e.g. caching,
annotations, etc.).
Thanks,
Nabeel.
On Sat, May 3, 2008 at 5:00 AM, Samisa Abeysinghe
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
For anyone who is interested: http://wso2.org/library/3532
Samisa...
--
Samisa Abeysinghe Director, Engineering; WSO2 Inc.
http://www.wso2.com/ - "The Open Source SOA Company"
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.16/1434 - Release Date: 5/15/2008 7:24 AM
--
Samisa Abeysinghe
Director, Engineering; WSO2 Inc.
http://www.wso2.com/ - "The Open Source SOA Company"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
