in reply to HTTP server guidance

To me this sounds almost the same as a database connection. If it was one, I'd recommend mod_perl and Apache::DBI. As it is none, there a few points to think about:

Has the backend a problem with idle connections?

Has the backend a problem with many connections?

Is there any kind of state in the backend connection?

If you can answer no to all these questions, then use mod_perl and just hold the connection in a global variable. It will stay there, one per webserver child, as long as the child lives.

# Pseudocode our $conn; sub handler { my $r = shift; $conn ||= connect(); send($conn, 'abc'); print recv($conn); return OK; }
And, configure the maximum, minimum idle and maximum idle number of childs to some values that match your setup...

Search, Ask, Know

Replies are listed 'Best First'.
Re: Re: HTTP server guidance
by DaveH (Monk) on Nov 27, 2003 at 16:10 UTC

    Hi Beechbone,

    You hit the nail on the head! The answer to all those questions is a resounding "no", so I think I'm going to go for some variation of your solution.

    The only problem might be "idle connections" (ideally, the protocol requires that keep-alive packets are sent on quiet lines), but I could easily solve this with a cron job which polls the server every minute for some 'no-op' request. Does anyone have a more elegant solution?

    Anyway, my thanks to everyone for your contributions. All responses were very gratefully received.

    Cheers,

    -- Dave :-)


    $q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print
      The cron won't help. The problem is that the connections are spread into the webserver childs, and when an http request comes in (from a client or the cron job) it is handled by a (more or less) random child. No way to make sure every child gets an request every 5 minutes.

      What happens if the connection times out? The server closes it and is happy, or does the backend server have any problems with it? And, is there any kind of "ping" message the perl wrapper could send to test if the connection is still alive?

      I would just let the connections time out and don't care. If a perl wrapper finds the connection dead, it just silently opens a new one.

      # $conn ||= connect(); if (not $conn or is_dead($conn) { $conn = connect(); } my $status = send($conn, 'abc'); if ($status == CONN_DEAD) { $conn = connect(); $status = send($conn, 'abc'); }

      Search, Ask, Know
        What happens if the connection times out? The server closes it and is happy, or does the backend server have any problems with it?

        No, thinking about it, the backend system should just happily close the connection. There should be no negative consequences of closing the connection beyond the fact that the next request will have to wait for it to re-establish (but we are talking about LAN-connected systems here, so I don't think that latency should be a big problem).

        And, is there any kind of "ping" message the perl wrapper could send to test if the connection is still alive?

        Yeah, you can send a "K0006" keep-alive message, in which case the server should respond likewise with a "K0006" response. This could serve as a "ping" I suppose. However, I may as well just see if the socket is dead, as you show in your example.

        I'm busy trawling throught the mod_perl API docs again at the moment... hopefully I'll be making a start on this soon. Thanks again for your support.

        Cheers,

        -- Dave :-)


        $q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print