Cheers for that. The ones I'm seeing at the moment are massive XML documents with a little bit of required data on either side. Its the industry standard schemas that do the "upscale" of the documents. This isn't unique to XML of course, no one would call EDI the most compact format in the world.
Steve On 31/01/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Steve Sorry we didn't publish all the data in graph format. The Mesh-5000 is doing pretty complex XML processing. The String-5000 (which is in the excel spreadsheet - we will add it to the page shortly) number was 444/sec. This is still doing some reasonable processing ( i.e. creating an array of 5000 strings versus a single big string). Paul On 1/31/07, Steve Jones <[EMAIL PROTECTED] > wrote: > > Looking on the graphsi was looking at the Mesh-5000 responses (hence 27 > tpc), I can't see the string-5000 one on the page (I may be going blind > however). > > 400 reqs/s would definately be superb, I just didn't see that when > looking at the Mesh-5000 numbers. > > Steve > > > On 31/01/07, Paul Fremantle < [EMAIL PROTECTED]> wrote: > > > Steve > > > > Please remember that these messages are being parsed into Java objects > > and also echo'ed. So this isn't a good comparison with a traditional > > messaging system (like MQ) where the messages are typically one-way and the > > actual parsing processing of the body isn't considered part of the test. > > > > The closest we did to your test was the echoStrings-5000 test which > > had a message size of 200k (therefore 400k throughput per message) and we > > got more that 400req/s which was completely saturating the 1Gb/s ethernet > > segment. I don't think you can really ask more?! > > > > Paul > > > > > > On 1/30/07, Steve Jones < [EMAIL PROTECTED]> wrote: > > > > > > Paul, > > > > > > Its interesting stuff, but I'd certainly say that "serious work" in > > > XML land can often be significantly above 4-6k, and often (when using > > > industry standard schemas) in the 200-500k range and pretty complex > > > structures. Which means around 30 tps from the graph which isn't very > > > much. One of the issues in industry is that there are great reasons to use > > > industry standard schemas but they are pretty evil things as they aim to > > > cover all cases, this makes them very inefficient. > > > > > > Have you folks done anything around how to scale B2B and domain to > > > domain scenarios with large documents? From my wikipedia ripping experience > > > I'd expect StAX to massively outperform JAXB due to the large envelope but > > > small content pieces of those schemas. > > > > > > I'd be happy to provide some test schemas that I've seen cause > > > trouble. > > > > > > Steve > > > > > > > > > On 30/01/07, Paul Fremantle < [EMAIL PROTECTED]> wrote: > > > > > > > A while back we had a discussion on whether Web Services are > > > > slow. > > > > > > > > Here is some data that I think concludes that SOAP can scale to > > > > high > > > > transaction rates (e.g. 300 million transactions a day). The test > > > > isn't a real-world test, but it does show that the overhead of > > > > SOAP > > > > processing is minimal with the latest toolkits. > > > > > > > > Some quotes from the article. > > > > ---------- > > > > > > > > This article shows the latest performance results of Apache Axis2 > > > > vs. > > > > Codehaus XFire, both Java implementations. The results demonstrate > > > > that modern Web Services engines can perform at very high > > > > transaction > > > > rates. > > > > > > > > Axis2 using the default ADB binding framework shows outstanding > > > > performance, with consistently better results than XFire/JAXB or > > > > Axis2/JAXB. > > > > > > > > Using either toolkit, the overhead of using XML and SOAP is no > > > > longer > > > > a limiting factor in writing distributed systems for most > > > > applications > > > > (with may be the exception of trading floors!). While these tests > > > > do > > > > not perform 'real' work, the fact that a XML messaging system can > > > > scale to more than 10 million transactions an hour on a single > > > > quad-core server shows that Web services can be used for > > > > significant > > > > systems applications. > > > > > > > > --------- > > > > > > > > Read more here: http://wso2.org/library/588 > > > > > > > > My disclaimer - I co-authored the document and I'm a committer on > > > > the > > > > Axis2 and other Apache WS projects. > > > > > > > > -- > > > > Paul Fremantle > > > > > > > > http://bloglines.com/blog/paulfremantle > > > > [EMAIL PROTECTED] <paul%40wso2.com> > > > > > > > > > > > > > > > > -- > > Paul Fremantle > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > http://bloglines.com/blog/paulfremantle > > [EMAIL PROTECTED] > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
