[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Unfair question: best Lisp for web development?

From: Graham Fawcett
Subject: Re: [Chicken-users] Unfair question: best Lisp for web development?
Date: Thu, 28 Feb 2008 09:37:26 -0500

Hi Daishi,

On Thu, Feb 28, 2008 at 1:28 AM, Daishi Kato <address@hidden> wrote:
> Graham Fawcett wrote:

>  > Sure. My first version was an SCGI server, but later I switched to
>  > HTTP. I usually host behind Apache, and moving from mod_scgi to
>  > mod_proxy was pretty straightforward, and in return it's much easier
>  > to test when Apache isn't running. I also like that using HTTP as the
>  > only protocol means that you can deploy apps in small-scale,
>  > standalone situations (e.g. "localhost" workstation apps).

>  I'm also curious on this for I'm now running a HTTP server
>  and thinking to change it to an SCGI server (using web-unity).
>  Is the performance technically the same in these cases?

SCGI performs very well. It is hard to find performance differences
between mod_scgi and mod_proxy performance. (I also used a custom SCGI
handler, so I can't speak for or against the current scgi egg.)

>  Also, do mod_scgi and mod_proxy handle long-lived connections
>  (a.k.a. COMET connections) very well?

Hm, good question. My guess is that they would both work, but I
haven't tried that. SCGI responses are closely based on the CGI model:
you print a 'Status: 200 OK' followed by your headers, and then write
out the response body. I believe that Apache / lighttpd will just
proxy your response stream back to the client.

Note that the SCGI protocol uses connections only once: SCGI is not
keepalive. But Apache can maintain keepalive connections with your
clients and simply use multiple SCGI connections to complete the work.

Some testing would be a good idea. You might also want to confirm that
your front-end Web server is not configured to time-out on
long-running connections.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]