Re: [PHPLIB] Re: [PHP3] persistent data From: Sascha Schumann (sascha <email protected>)
Date: 03/30/00

On Thu, Mar 30, 2000 at 05:52:43PM +0200, Kristian Koehntopp wrote:
> On Thu, Mar 30, 2000 at 02:33:28PM +0200, Sascha Schumann wrote:
> > Well, the penalty for storing simple strings is still quite high.
>
> Yes, that is true. That is why the session module in PHP4 is
> worthwile the effort.
>
> Still PHPLIB with a MySQL backend was fast enough to keep
> Zend.COM online through their /. 15 minutes of fame. I think we
> can consider that performant enough for most PHPLIB users.

The site became slow very quickly. The problem there was that they
did not have enough RAM and the boxes swapped themselves to death.
As I understood Zeev they have multiple front web servers and a
MySQL backend. He later asked me whether the files handler would
work reliably over NFS, so they are probably evaluating other solutions
as well.

> > Shared memory reduces the number of system calls even further, and
> > thus should be faster for keeping this kind of data around. Less
> > context switches, more speed.
>
> In PHP4 shared memory sessions the system overhead to sessions
> became so small that the limiting factor is the locking nature
> of sessions themselves: If process #1 is producing a page for
> session #17, it has to keep a lock on _all_ session variables
> pertaining to session #17. Process #2, belonging to the same
> session (for example in a frameset), is being locked out and
> effectively all pages of that session are serialized.
>
> That were not the case if PHP4 sessions were able to lock
> individual variable names or even individual values (I would not
> pursue the latter, it is a very difficult project).

Yea, we discussed this at the PDM. I don't think it fits into the
current session model of PHP 4. The majority of apps will be ok
with the conservative locking method we employ currently.

> Of course
> such a thing is impossible to do efficiently with PHPLIB
> sessions... And of course such behaviour should be optional as
> it requires support from the code using it (i.e. you have to
> wrap locking/unlocking instructions around your variable usage).
>
> The best you can to in PHPLIB is not to use locking at all (the
> default) and to leave of the page_close() at all but one page of
> a frameset (making the noncontent pages of the frameset
> read-only with respect to the session data).

That's an interesting idea. Users could flag pages as read-only WRT
session data. Then we could have multiple concurrent readers.

- Sascha
-
PHP3 Base Library Mailing List. Send messages to <phplib <email protected>>.
To unsubscribe, send "unsubscribe" to <phplib-request <email protected>> in
the body, not the subject, of your message.