471,624 Members | 1,832 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,624 software developers and data experts.

Persistent connections not limited to one Apache-process?

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
KeepAliveTimeout 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

Jul 17 '05 #1
5 2619
Felix E. Klee <fe********@inka.de> wrote:
[snip]
What do you recommend? Are there standard tools for that purpose? Any
ideas?


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.

Jul 17 '05 #2
At 10 Jun 2005 00:58:04 GMT,
Daniel Tryba wrote:
Is there an actual problem with opening 1 tcp socket to the nntp
server per http request?
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.
If there is you can:
-write a daemon like you suggested, can be written in any language you
feel comfortale with (that includes php).
I'm unlikely the first person with such a problem, so I was hoping for a
pointer to a ready made solution.
-switch (partially) to an other enviroment which actually has support
for threading (eg Java/Servlets)


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

Jul 17 '05 #3
At Fri, 10 Jun 2005 11:08:22 +0200,
Felix E. Klee wrote:
* Open a persistent connection to the PostgreSQL database for the perl
scripts doing the authentication.


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

--
Felix E. Klee

Jul 17 '05 #4
Felix E. Klee <fe********@inka.de> wrote:
If there is you can:
-write a daemon like you suggested, can be written in any language you
feel comfortale with (that includes php).


I'm unlikely the first person with such a problem, so I was hoping for a
pointer to a ready made solution.


If that's true, you shouldn't have any trouble finding them :)
On the otherhand, it's quite simple to implement.
-switch (partially) to an other enviroment which actually has support
for threading (eg Java/Servlets)


How could that help?


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).

Jul 17 '05 #5
At 10 Jun 2005 13:12:42 GMT,
Daniel Tryba wrote:
If there is you can:
-write a daemon like you suggested, can be written in any language you
feel comfortale with (that includes php).


I'm unlikely the first person with such a problem, so I was hoping for a
pointer to a ready made solution.


[...]
On the otherhand, it's quite simple to implement.


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

Jul 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Randell D. | last post: by
2 posts views Thread by Steve Jenkins | last post: by
2 posts views Thread by Ivan | last post: by
2 posts views Thread by Jim Hubbard | last post: by
reply views Thread by manji | last post: by
6 posts views Thread by David Rasmussen | last post: by
5 posts views Thread by lawpoop | last post: by
2 posts views Thread by Scott Sharkey | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.