Re: Has anyone used multiplexed connections with FastCGI?

Thanks, Darren. Was kind of afraid the answer might be similar to yours (few
or no servers), given that searching did not turn up any evidence. :)

Seems highly unlikely the Apache 1.x series (probably the biggest use of
FastCGI, early on) could have supported multiplexed connections. Given a
stable Apache module, and few/no FastCGI applications that can accept
multiplexed connections, there would no reason to put in work in that area
for Apache 2.x (even if feasible).

My interest is a little different, as I am looking at solving C10K class
problems. Can I build a massively scalable solution using server-side
Javascript (the Google V8 engine), no threads, and strict
non-blocking/asynchronous I/O? (Something like "node.js" but usable via
FastCGI.) Javascript interpreters are very strong on sandboxing (due to the
browser heritage), so keeping large numbers of per-request contexts is
straightforward.

I would guess that keeping down the number of connections (via multiplexing)
could be an advantage, for very large numbers of connections.

I have long  been interested in both single-threaded/non-blocking servers,
and in server-side Javascript.
http://bannister.us/weblog/2009/12/30/almost-but-not-quite-server-side-javascript/
http://bannister.us/weblog/2006/12/19/revisiting-server-side-javascript/

Take this as an experiment. :)

The current code is at:
http://svn.bannister.us/public/cgi-1/

Don't bother looking, as it is far too early.


On Sun, Jan 31, 2010 at 6:10 PM, Darren Garvey <[email protected]>wrote:

> Hi Preston,
>
> On 31 January 2010 20:33, Preston L. Bannister <preston-ZeqQeWHeiHFcT1eoJ+6/[email protected]>wrote:
>
>> Does anyone use multiplexed connections with FastCGI?
>
>
> I don't know of any servers - free or commercial - which support
> multiplexed requests concurrently over a single connection.
>
> Are there frontends that support multiplexed connections (which I could get
>> from reading the sources, eventually), and do any work reliably (which may
>> be harder to determine)?
>
>
> <shameless_plug>
> I'm developing a (c++) FastCGI library that's "supposed" to support
> multiplexed connections, but I've never been able to test this aspect of it
> (ie. multiplexing) so can't claim to support it either completely or
> reliably. That said, I am currently rewriting the docs for this library and
> hope to wrap a release shortly, free-time permitting.
> </shameless_plug>
>
> (Started writing a FastCGI application, putting in support for multiplexed
>> connections, and wondering if this might be a bad idea.)
>>
>
> Supporting multiplexing caused me some headaches with the unbuffered
> approach I took. I still wonder how much efficiency can be gained from
> supporting multiplexed connections and if it is worth it in the end. The
> Jury's out until there are some performance numbers against a
> multiplexing-enabled production server. I haven't found that supporting
> multiplexing causes any noticeable runtime overhead, but does add some
> complexity to the implementation because of multithreaded considerations.
>
> If you'd like to share your ideas / implementation, let me know (offline if
> you prefer).
>
> Cheers,
> Darren
>
> [1] If you are interested, code is available at
> https://svn.boost.org/trac/boost/browser/sandbox/SOC/2007/cgi/. Examples
> are in libs/cgi/example.
>

_______________________________________________
FastCGI-developers mailing list
FastCGI-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers