Persistent connections not limited to one Apache-process?

[Felix E. Klee]

I've set up a PHP web application where users can log in and open a
connection to a NNTP-server. There is a *one-to-one* relationship
between sessions and NNTP-connections (i.e. exactly one NNTP-connection
per session, and exactly one session per NNTP-connection).

Now, I'd like to have these connections be persistent. So I started
using "pfsockopen " instead of "fsockopen" and set Apache's
KeepAliveTimeou t to a very high value. However, this doesn't work all
that great: Often browser-connections are closed prematurely and some
browsers have trouble with KeepAlive, anyway. After a
browser-connection has been closed, the next browser request will most
likely be answered by a different Apache process, and this process will
open a *different* persistent connection. In a nutshell:

* Persistency of the NNTP-connections over a lengthy period of time is
nearly impossible (unless the browser and the web server play well
together).

* More than one connection is created per session, which is a waste of
resources.

A solution that comes into my mind is using a separate daemon running on
the same machine as the web server. It would open persistent
NNTP-connections and connect them to a local socket. A PHP session
could then connect to that socket.

What do you recommend? Are there standard tools for that purpose? Any
ideas?

BTW, I'm running PHP4 on an Apache 2 LINUX-server, but upgrading
e.g. PHP should be no big problem.

--
Felix E. Klee

[Daniel Tryba]

Re: Persistent connections not limited to one Apache-process?

Felix E. Klee <felix.klee@ink a.de> wrote:
[snip][color=blue]
> What do you recommend? Are there standard tools for that purpose? Any
> ideas?[/color]

Rule 1: don't optimize
Rule 2: don't optimize (yet)

Is there an actual problem with opening 1 tcp socket to the nntp server
per http request?

If there is you can:
-write a daemon like you suggested, can be written in any language you
feel comfortale with (that includes php).
-switch (partially) to an other enviroment which actually has support
for threading (eg Java/Servlets)

But that only fixes problems where setting up an initial connection to a
(nttp) server takes a huge amount of time (relatively speaking). But
that might also mean there is a network configuration error hidden
somewhere.

[Felix E. Klee]

Re: Persistent connections not limited to one Apache-process?

At 10 Jun 2005 00:58:04 GMT,
Daniel Tryba wrote:[color=blue]
> Is there an actual problem with opening 1 tcp socket to the nntp
> server per http request?[/color]

Yes, it takes several seconds since:

1. For authenticating a user, the news server needs to contact a
PostgreSQL database twice (once for verifying UID and password, and
once for deciding which groups the user has access to).

2. The server hosting the PostgreSQL database is quite slow.

Some alternatives to opening a persistent connection to the news server:

* Cache the login and groups data in a simple database that doesn't take
as long to connect to as PostgreSQL.

* Open a persistent connection to the PostgreSQL database for the perl
scripts doing the authentication.

Both of the above solutions appear about as complex as opening a
persistent connection to the news server. So I'm not too fond of them,
especially as they will be a bit slower.
[color=blue]
> If there is you can:
> -write a daemon like you suggested, can be written in any language you
> feel comfortale with (that includes php).[/color]

I'm unlikely the first person with such a problem, so I was hoping for a
pointer to a ready made solution.
[color=blue]
> -switch (partially) to an other enviroment which actually has support
> for threading (eg Java/Servlets)[/color]

How could that help? However, concerning threading, it may be
interesting to try out how "pfsockopen " would behave with a
multithreaded Apache (see e.g. module MPM worker).

--
Felix E. Klee

[Felix E. Klee]

Re: Persistent connections not limited to one Apache-process?

At Fri, 10 Jun 2005 11:08:22 +0200,
Felix E. Klee wrote:[color=blue]
> * Open a persistent connection to the PostgreSQL database for the perl
> scripts doing the authentication.[/color]

Actually, this may be simpler than I thought it is: I discovered
SpeedyCGI and "DBI::connect_c ached".

--
Felix E. Klee

[Daniel Tryba]

Re: Persistent connections not limited to one Apache-process?

Felix E. Klee <felix.klee@ink a.de> wrote:[color=blue][color=green]
>> If there is you can:
>> -write a daemon like you suggested, can be written in any language you
>> feel comfortale with (that includes php).[/color]
>
> I'm unlikely the first person with such a problem, so I was hoping for a
> pointer to a ready made solution.[/color]

If that's true, you shouldn't have any trouble finding them :)
On the otherhand, it's quite simple to implement.
[color=blue][color=green]
>> -switch (partially) to an other enviroment which actually has support
>> for threading (eg Java/Servlets)[/color]
>
> How could that help?[/color]

Because in that environment you don't need to build an external daemon.
One could either create the daemon in an other thread, or in the case of
Java/Servlets one could just store the socket in the session (never
tried this but IMHO that simply should work).

[Felix E. Klee]

Re: Persistent connections not limited to one Apache-process?

At 10 Jun 2005 13:12:42 GMT,
Daniel Tryba wrote:[color=blue][color=green][color=darkred]
> >> If there is you can:
> >> -write a daemon like you suggested, can be written in any language you
> >> feel comfortale with (that includes php).[/color]
> >
> > I'm unlikely the first person with such a problem, so I was hoping for a
> > pointer to a ready made solution.[/color]
>
> [...]
> On the otherhand, it's quite simple to implement.[/color]

Hm, I'm afraid that it's not as simple as it looks at first sight: One
problem is that, although there is a one-to-one relationship between
sessions and connections, a user may run the same session in two
different browser windows which may cause two different PHP scripts to
access the same connection simultaneously.

--
Felix E. Klee