Hi Eric,
Regarding, tuning the DataSource threshold size for switching from
in-memory to file based; it cannot be achieved using the build that I
have given to you. But I have fixed this, so that you can provide the
following properties in the synapse.properties file to change the
threshold values.
synapse.temp_data.chunk.size
synapse.temp_data.chunk.threshold
I will give a build on tomorrow with these changes and a detailed
description on using these properties.
Thanks,
Ruwan
Hubert, Eric wrote:
Hi all,
today we conducted some performance measuring regarding response times
with low traffic (3-6 concurrent requests) using the Hessian protocol
support.
Unfortunately when using the ESB the response times increased by about
30% in comparison to direct invocation. The test case only included a
proxy service with a send mediator using a fixed endpoint, no routing
decision, no logging/tracing. CPU load on the ESB had been minimal (<
5%).
While checking the esb log file I saw a lot of entries like that:
2008-04-28 11:04:25,255 [-] [Finalizer] WARN TemporaryData Cleaning up
unreleased temporary file work/temp/esb/tmp_43238.dat
2008-04-28 11:04:25,255 [-] [Finalizer] WARN TemporaryData Cleaning up
unreleased temporary file work/temp/esb/tmp_43239.dat
2008-04-28 11:04:25,255 [-] [Finalizer] WARN TemporaryData Cleaning up
unreleased temporary file work/temp/esb/tmp_43240.dat
I think this is related to the way "big" responses are handled. They are
streamed and temporarily written to disc, because they are larger than
some internal buffer. The warning may indicate that the client code does
not properly release the resources (in this case the temp file) and some
utility class does its best to compensate this misbehaviour through
fixing this inside a finalize method and logging the above warning (only
my blind guess).
Could you please check this and fix it, if I'm not wrong with my
uneducated guess! ;-)
More importantly I'm asking myself whether the IO interaction may cause
some notably delay. What is the default value for that buffer? It seems
to be very small (1 or 2 kb). How can I override this default value? Our
responses are not that big and I'm less concerned about used memory than
about the performance. I hope this one will not be hard-coded. ;-) No,
I'm just kidding. I'm pretty sure you will have provided a mechanism to
override this. Maybe we could also discuss about a better/optimal
default value?
Sorry guys for not being more concrete. If I had the time, I would have
taken a look at the source code by myself.
The performance numbers for the SOAP message are slightly better, though
not as good as I would have expected. Do you have any general hints on
tuning the performance? Memory wasn't used much during the test. Is any
OS level tuning advisable for such low traffic scenarios?
I will try to narrow down the average overhead for different message
sizes and service response times, because I could not see a constant
absolute overhead in ms which would be related to the two additional
network hops (incoming and outgoing).
Thanks,
Eric
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
