jeljer te Wies wrote:
>> Then you're not just squirting the object over a raw TCP socket; you're 
>> adding your own proprietary encapsulation/framing protocol around it. 
>> And if you're going to do that, you might as well add another field 
>> which says whether it's JSON or XML or whatever, and hence the problem 
>> is solved.
> 
> Yes you are right. I could use an extra field. But I need the ability to 
> add more "adapters" when the esb gets more connections!..

So either force the clients to use the same protocol you have defined, 
or listen on different ports for the different protocols you want to 
use. It sounds like you have now gone with the second option.

> Yes you are totally right ! but it is not really the Ruby who is slow 
> but the many sql database connections who are need by every request (see 
> the attachment for a quick overview)

That's what I mean. If the overhead of Ruby is small compared to the 
overhead of whatever is going on in the SQL database, then there's 
little point rewriting the Ruby part in C++. Measure first, optimise 
later.

Remember of course there is a different between *latency* and 
*throughput*. You can have a high latency for an individual request, but 
still serve large numbers of requests if there are lots of concurrent 
clients and they are not contending on the same resource.

Regards,

Brian.
-- 
Posted via http://www.ruby-forum.com/.