Re: haproxy and orbited (COMET server)

From: Christoph Dorn <christoph#christophdorn.com>
Date: Thu, 31 Jan 2008 13:30:55 -0700

Thanks for the detailed response Willy.

I apologize for not being more specific about COMET.

The "COMET" concept encompasses the streaming of data to the client where the server is able to push new data to the client via a HTTP connection which the client opens to the server and the server keeps open for an indefinite period of time.

The server must be able to handle a large number of open client connections (subscribers) and provide a mechanism for an application to trigger events to be sent to the subscribers, usually via another TPC-based control protocol.

Orbited is a python implementation of such a server, Meteor is a perl implementation. The Meteor website (http://meteorserver.org/) has some excellent documentation on the concept.

The comment about apache not being able to handle COMET well was based on the fact that it does not generally handle a large number of parallel open connections well (with code holding the connection and polling a que for events). You can find some details about the philosophy behind the implementation of orbited here
(http://orbited.org/svn/orbit/trunk/docs/scalable_comet_speaking_notes) which should give you a pretty good idea of the challenge.

To summarize again, the solution I seek is to be able to service HTTP requests on the same hostname and port where the requests for one set of URI's get sent to apache and the requests for a second set of URI's get sent to a COMET-optimized server that will handle a large number of open connections.

Looking forward to your response.

Thanks!
Christoph

Willy Tarreau wrote:
> Hi,
>
> On Wed, Jan 30, 2008 at 01:08:43PM -0700, Christoph Dorn wrote:

>> I was wondering if it is possible/practical to proxy a specific URL to
>> an orbited daemon (http://www.orbited.org/).
>>
>> I have a basic setup that proxies "GET /orbited" to the daemon running
>> on port 8000. HAProxy connects but there are some problems:
>>
>> 1) orbited is receiving connections from HAProxy every second even
>> though I have the server "check" option not set.

>
> That seems strange to me, are you really sure that you didn't forget
> one server with a "check" somewhere ? I usually disable checks on my
> tests configs when I strace in order not to be polluted, and I am sure
> that no check is send when not explicitly stated.
>
> Maybe you have an outer component which regularly checks haproxy which
> in turn forwards the connection to your server ?
>

>> 2) When a client connects to "/orbited" on haproxy the request goes to
>> orbited just fine, however the connection is dropped after 5 seconds (I
>> presume by haproxy)

>
> yes, it is dropped upon client or server inactivity. That also means that
> you have not set "option httpclose" otherwise it would have been dropped
> immediately after the end of data retrieval.
>

>> which defeats the purpose of COMET :)

>
> I'm sorry, but I don't know what COMET is. I've checked the "orbited"
> site above which is said to be written for comet, but with no obvious link
> about this comet. Also, the first 3 pages of google about the subject look
> irrelevant :-/
>
> Could you please explain to me/us what it consists in ?
>

>> 3) When a client is connected to "/orbited" and a trigger is sent to the
>> orbited daemon the event is not relayed to the client. I presume haproxy
>> does not continue to listen for responses from orbited daemon as the
>> connection is already closed.

>
> If the server replies after the connection is closed, it means you have
> too short timeouts on haproxy and that it doesn't grant enough time to
> the server to reply. But you talked about 5 seconds. Most often, this is
> considered quite long nowadays on the net.
>

>> The whole reason for wanting to use HAProxy is to direct a specific URI
>> to a socket running on a different port than your standard apache so
>> that there are no javascript security problems on the browser side.
>> Now if HAProxy has the same limitations as apache/backend when many
>> client connections are kept open for a long time then using HAProxy is
>> obviously not a solution either.

>
> Well, haproxy has very different limitations from apache, both use quite
> opposite models, and both are good for some workloads and terrible for
> others. What I'm a bit afraid of is that if your application has trouble
> with two such diametrically opposite solutions/models, I don't know if
> you will easily find something compatible with it and which at the same
> time scales.
>

>> Any comments on this setup? Any other solutions that anyone is running
>> to get COMET working on same hostname:port as main website?

>
> Lacking info on this "COMET", I don't know. Maybe it has some strange
> requirements which are not fully compatible with HTTP proxies, I don't
> know. Have you looked at the pound load balancer ? It is quite simple
> and efficient, it supports URL switching, keep-alive (which may probably
> help in your case). It doesn't scale as far as haproxy, but given that
> Orbited will be bound to Python's performance anyway, there is no reason
> that your expected performance level would be incompatible with it I
> think. However, I can't juge whether it will be functionally compatible.
>

>> Thanks!
>> Christoph

>
> Regards,
> Willy
>
>
Received on 2008/01/31 21:30