On Binary XML: CXF has fast infoset support already provided. See confluence for instructions.
On Sun, Sep 14, 2008 at 10:47 AM, Kent Närling <[EMAIL PROTECTED]> wrote: > 2008/9/12 Christian Vest Hansen <[EMAIL PROTECTED]> > >> On Fri, Sep 12, 2008 at 11:07 AM, Kent Närling <[EMAIL PROTECTED]> >> wrote: >> > Hi! >> > I guess this might have been answered here before, but I searched the >> lists >> > and the FAQ:s and could not find anything so I will take the risk ... ;-) >> > >> > What ARE reasonable overheads using CXF Webservices? for instance >> compared >> > to RMI/Beans etc? >> >> I would never recommend RMI. It is based on Java serialization, which >> is fundamentally broken. > > Yes, naturally, for compatibility it is horrible, so I would never compare > it to webservices etc ;-) > > And I didn't intend to compare with RMI as an alternative, more to get a > feeling of the "cost" of sebservices/SOAP compared to less robust but more > low level alternatives. > > >> >> I'd suggest using Googles Protocol Buffers instead. > > Ok, Will look into that ... > > >> >> >> > >> > We did some measurments and found that some basic calls got between 3-5 >> > milliseconds of overhead/response time (using a dummy implementation). >> > Is this normal? or does it sound high? can this be tuned significantly? >> >> Considering this is (presumably) over a network connection, then this >> latency looks to me to be quite good. But I wonder how this was > > > No, actually it was not! > I simply initialized a (mockup) webservice , published it and then called it > from within the same process > (tried both with single thread and multiple threads with comparable results) > >> >> measured. The process-schedulers in most operating systems use 10 ms >> timeslices, so unless you really know your way around benchmarking and >> statistical analysis, you can expect measurements in the < 20 ms scale >> to be very inaccurate. > > > Very true, forgot that for a moment, will doublecheck that. > But the analysis is based on thousands of calls and then calculating the > average/call. > Also, I used System.nanoTime() which should be more accurate. > > >> >> I suppose it can be tuned by using a binary XML format. There has been >> some talk about on this list, but I can't find anything on the wiki so >> I don't know if it is actually feasible. > > > Ok, will keep my eyes open for this. > > >> >> > >> > Mainly I need to know to decide our strategy for using webservices etc >> > >> > For our external interface this latency/overhead is not an issue, but we >> > have discussed using webservices as an internal interface in a SOA >> > architecture, but then this overhead would not be practical... >> >> Is latency really that important to you? Or is it actually throughput >> that is your real concern? > > > Well, maybe not as long as it is not a symptom of overhead so your point is > very valid. > > >> >> Only a proper load-test can tell whether or not the throughput will be >> good enough. My experience is that you throughput-bottleneck is much >> more likely to be in your application code that in CXF itself. At >> least, that is my conclusion for load that ranges up to 20.000 >> requests per minute. > > > This is a very interesting comparison!! 333 TPS? > Can you qualify that a bit more? is that on a single machine? > > If performance on levels of 100-200 TPS is achievable with webservices is > easily achievable on a single machine (without heavy tuning etc), then I > think we should be happy enough! :-) > > >> >> I don't know anything about systems that need to live up to real-time >> gaurantees, though. > > > No, we do have some stringent demands on our systems, but I wouldn't > qualify them as "real-time guarantees" > > >> >> > >> > Best regards, >> > Kent >> > >> >> >> >> -- >> Venlig hilsen / Kind regards, >> Christian Vest Hansen. >> >
