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
