Hi all, Adding to Asankha..
Replying to Claus, on VTD-XML, UltraESB too is using VTD-XML to do xpath etc in its enhanced version (due to the same licensing reasons mentioned by Claus) of the perf tests. In the same manner, we could test a vanilla servicemix version as well as an enhanced servicemix version with VTD-XML parsing enabled, as we would like to test the downloadable version an any enhanced versions separately. On another note, I saw in this discussion Claus mentioning about, "spooling into the Disk" with some sort of a streaming cache, for that we could utilize a RAM-DISK which is already setup on the AMI instance (/tmp/ram) containing the performance setup (UltraESB is utilizing this for its file-cache). We really appreciate any feedback on improving this test suite to support other ESB scenarios, than the once using HTTP transport (which I believe is being tested well with WS and REST). Also note that the AMI is open and anybody can run the tests them selves too, if they have an EC2 account. (IIRC, Apache has some for Apache projects) Thanks, Ruwan On Fri, Aug 31, 2012 at 12:46 PM, asankha <asankha.pub...@gmail.com> wrote: > Hi Christian, Dan and Claus > > >And the fact that they use SMX 4.3.0 which is an old release > (4.3.0/03-Mar-2011 13:25) > >Since SMX 4.4.0, 4.4.1, and 4.4.2 has been released. > > First of all I must apologize for this.. But I visited the ServiceMix > http://servicemix.apache.org/download.html download page just now, and it > still tells me "The latest release is the ServiceMix 4.3.0 Release. We > strongly encourage all users to use this Release" - so I'm sure something > needs to be corrected somewhere.. > > We would really like to work with you all to define how the test suite > should be extended - like Dan said, we made some enhancements this round, > and expect to bring in JSON/REST test cases. Other transports such as > File/JMS etc would be more difficult to test - especially for performance - > but if you could propose clever ways of doing it, we'd certainly like to > include them. The only reason we do not test large messages for all > scenarios, and large numbers of messages for high concurrency levels etc, > is > just to make the total test run within a decent time across all ESBs > > As for the updates submitted by Christian, we will run them ASAP - and get > back to you. This was our original objective as well when we > http://www.prweb.com/releases/2012/6/prweb9651239.htm announced Round 6 > and > asked for updates from any vendors or contributors, and a chance to > optimize > and fine tune the configurations before the final tests were run > > We did work cooperatively with those who replied to us, and wanted to > ensure > a fair benchmark that was also transparent - thus we accepted almost all of > the suggestions and enhancements that came in - and I'm sure participating > in the round helped those ESBs find out some areas where they could improve > as well, which is good. > > Again, I'd like to commit that we'd like to cooperate with you on this, and > work together - to make a better, fair and transparent benchmark for ESBs! > > regards > asankha > > AdroitLogic Private Ltd > http://www.adroitlogic.org > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/ESB-Performance-Testing-Round-6-tp5718215p5718459.html > Sent from the Camel Development mailing list archive at Nabble.com. > -- Ruwan Linton Member, Apache Software Foundation; http://www.apache.org Director of Engineering; http://adroitlogic.org phone: +94 11 251 6899 email: ru...@adroitlogic.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
