Web Servers on Unix and Linux - issue with process-per-request

Author

issue with process-per-request

Yan Zhou

2004-09-23, 9:20 am

Hi,

I have seen some discussion on how process-per-request is probably good in
performance. Without the headache of getting in multi-thread programming, it
is a good choice.

But I wonder how would a process-per-request system keep session states,
since subsequent requests within the same session can be served by different
processes? I suppose the same issue lies in multi-threading system as well.

Thanks.
Yan

Hornet

2004-09-23, 9:20 am

Yan Zhou wrote in message ...
> Hi,
> I have seen some discussion on how process-per-request is probably good in
> performance. Without the headache of getting in multi-thread programming, it
> is a good choice.
> But I wonder how would a process-per-request system keep session states,
> since subsequent requests within the same session can be served by different
> processes? I suppose the same issue lies in multi-threading system as well.
> Thanks.
> Yan

This is a general programming question.
In most of cases, more processes = less performance.
Another thing to mention is ,in most of cases, at some point you will have to
synchronize used processes so they execute one-by-one, and not in parallel which
is better.
Less synchronization = more performance.
Exchanging data between processes would require synchronization.
I hope this helps,
regards

Yan Zhou

2004-09-23, 9:20 am

I have no problem with performance or synchronization, but I would like to
know what are some strategys to keep session states since different
processes/threads can serve requests within the same user session.

Yan

Eric Schwartz

2004-09-23, 9:20 am

"Yan Zhou" <yzhou@medplus.com_REMOVE> writes:
> I have no problem with performance or synchronization, but I would like to
> know what are some strategys to keep session states since different
> processes/threads can serve requests within the same user session.

This is a basic problem with trying to use a stateless protocol for a
stateful application. Fortunately, since it's so basic, everybody has
solved it already. Whatever language you are using will have at least
several mechanisms for keeping session state. In the case of Perl,
several hundred, most likely.

I strongly recommend you look into the tools provided by whatever
language you're writing your code in, and use those, instead of trying
to reinvent them.

To specifically answer your question, the basic idea is that you
associate some unique ID with a session, and then store the
information associated with that session on the server somewhere, and
store the ID with the user somehow (either via a cookie, or via
rewriting URLs to include the session ID somehow).

Then, each time the user requests a resource, you are also handed the
session ID, which you then use to fetch the session information back
from wherever you stored it. Again, there exist modules right now for
nearly every language that will store session information in shared
memory, in files, in databases, and who knows where else. Use them.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

Hornet

2004-09-23, 9:20 am

Yan Zhou wrote in message ...
> I have no problem with performance or synchronization, but I would like to
> know what are some strategys to keep session states since different
> processes/threads can serve requests within the same user session.

I assume that processes need to exchange that information.
To my best knowledge, if two or more processes are aware of same information
acquired after processes have been created, they are using some form of
inter-process communication.
Hope this helps,