[FoRK] overhead of RESTful stuff

Eugen Leitl eugen at leitl.org
Fri Mar 9 01:03:21 PST 2012


On Thu, Mar 08, 2012 at 09:42:11AM -0800, Stephen Williams wrote:
> That is assuming that you have the right application server model.  
> Finally, good models are well known now.  However, many implementations 
> are done poorly the first time around: thread per request, no or poor 
> queuing of new requests, no pipelining or connection reuse, etc.

This is about building large scale applications by integrating
coarse components (preventing impedance mismatch between Windows/DLL,
C/C++, Linux, Java. Assume the worst practices, the most performance-ignorant
coder monkeys unable to tell a procedure call from a REST API call.

> Additionally, a lot of popular components are not very memory or CPU 
> efficient.  XML libraries for instance are often ridiculously large and 
> fairly inefficient.  Communication between web servers and app components 

Beats home-grown, in our case.

> can kill performance and be a bottleneck.  And then the application 
> communication model can be very poor.  Things are better with AJAX+REST, 

AJAX never happens, at least this level.

> if done well, but many apps are overly chatty and/or fragile.
>
> Good use of memcached and similar solves a lot of people's problems.  As can certain database solutions, NOSQL and sharded MySQL etc.

Doesn't apply, caching is completely useless here.

> Although used incorrectly a lot of the time, lightweight message queue 
> components can drastically improve efficiency, scalability, resilience, 
> flexibility, and development evolution.  One of the best overall 
> architectures is to have a high performance web server (nginx is one of 
> the most popular) that connects directly with very efficient message 
> queues to application engines, distributed and multiplexed as necessary.

I don't see how nginx/memcached can be integrated into an increasingly
Java-contaminated environment with plenty of C/C++ components running
on Windows and Linux back end.

> Although mostly ignored right now, depending on what data needs you have, 
> you might want to consider W3C EXI (which I worked on).  Although they 
> left out a couple things I think are crucial to fully optimizing things 
> like REST traffic, it is a good base.  I keep wanting to get excited 
> about creating a version that has those features (deltas, externalized 
> metadata objects for "compiled" schema, HBAF (hybrid byte aligned 
> format)), but other tasks are coming first.

Thanks for the pointer.

> These days, both Java and Javascript have heavily optimized JIT compiling 
> runtimes (only partway there for DEX-based Java on Android though), so 
> there's usually little to worry about performance wise on endpoints.  The 
> algorithms and architecture are far more important.

Optimization is unheard of, so paradoxically the overhead of
back-end (minutes to seconds to ms) will probably make the API more palatable.

> The SOA stack is terrible, don't use it.  Use OAUTH authenticated HTTPS 

Authentication doesn't apply, it's all machine to machine on trusted network.

> with simple object models.  Nearly everyone uses JSON for this now, with 
> some (usually bad) use of XML.  I like GSON for JSON parsing in Java, and 
> my Ssx parser for most application level parsing of XML.  Ssx is fast, 
> tiny, and highly simplified for concise development, but currently only 
> parses.  For outputting XML, in most cases you just want to do the 
> obvious construction which is generally faster.
>
> EXI, especially with my added features, would be the most efficient by far in size, parse speed, least CPU.

Thanks again.

> Stephen
>
> On 3/8/12 7:26 AM, Gregory Alan Bolcer wrote:
>> If you use a compiler like Excelsior Jet, performance is the same.
>>
>> For REST, most Java stacks are pretty mature.  There are some C++ + 
>> other scripting languages that are straight across functionality 
>> transfers.
>>
>> Hardware is a commodity, so any hardware costs will more than be made up for by development and maintenance costs.
>>
>> Most modern serves have dual or quad GBit ethernet, so a proper network 
>> architecture which takes into account routing front ends and good 
>> balancing using proper net naming and setup shouldn't be a problem.
>>
>> The biggest bottlenecks for almost 99% of REST based applications will be disk i/o, memory size, and then cpu.
>>
>> Greg
>>
>> On 3/8/2012 4:25 AM, Eugen Leitl wrote:
>>>
>>> There's some enthusiasm for SOA and RESTful stuff at my dayjob lately
>>> (yeah, we're always trailing state of the art by a decade or two),
>>> so I'm worried about overhead. These Java wonks don't have a good
>>> grasp of the entire hardware/network stack, and potential overhead
>>> of calls.
>>>
>>> First Java, how much overhead relative to C/C++ are we looking
>>> at? I estimate a factor of 5-10 in terms of hardware budget
>>> (more fat nodes, or many more the leaner nodes we're currently
>>> using). Is this about right or too pessimistic?
>>>
>>> I estimate that a lean box will crap out at about ~kHz of RESTful
>>> calls, especially if it's all a big wad of Java oozing behind the
>>> NIC. Is that about right? Linux/Windows differ much here?
>>>
>>> In terms of networking, is GBit Ethernet going to become a
>>> bottleneck for building applications from REST interfaces?
>>>
>>> Are any of you using REST on InfiniBand or is the idea insane
>>> in general, given the (probably awful) overhead?
>
> -- 
> Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: 
> http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 
> F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: 
> http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig 
> twitter.com/scienteer
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


More information about the FoRK mailing list