Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-30 Thread Marcus Börger
At 03:52 30.05.2002, Yasuo Ohgaki wrote: Steve Meyers wrote: Well, you didn't try it with MySQL, which is significantly faster than Oracle and Postgres for most stuff. In any case, I agree that msession is probably a better solution -- I just think that having built-in MySQL session support

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-30 Thread Steve Meyers
Yasuo Ohgaki wrote: Marcus Börger wrote: At 03:52 30.05.2002, Yasuo Ohgaki wrote: From my expirience postgres is slower if you use referential integrity (what you should do) but this you cannot do in mysql (and therefore it is some kind of data storage but not a real rdbms). Just to

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-29 Thread Steve Meyers
[EMAIL PROTECTED] wrote: At 10:20 25/05/2002 -0400, [EMAIL PROTECTED] wrote: Marginalizing this capability IMHO is not the right direction, I think there should, in fact, be a stronger push for this sort of capability to be built in by default. Agree with that too... but if something like

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-29 Thread mlwmohawk
[EMAIL PROTECTED] wrote: At 10:20 25/05/2002 -0400, [EMAIL PROTECTED] wrote: Marginalizing this capability IMHO is not the right direction, I think there should, in fact, be a stronger push for this sort of capability to be built in by default. Agree with that too... but if

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-29 Thread Steve Meyers
[EMAIL PROTECTED] wrote: The problem with using databases are they they are expensive and they are slow. A generalized PostgreSQL session manager would be cool, I have actually been thinking about such an extension. Using the schema from the PG msession plugin, it would be fairly easy.

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-29 Thread mlwmohawk
[EMAIL PROTECTED] wrote: The problem with using databases are they they are expensive and they are slow. A generalized PostgreSQL session manager would be cool, I have actually been thinking about such an extension. Using the schema from the PG msession plugin, it would be fairly

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-29 Thread Steve Meyers
[EMAIL PROTECTED] wrote: I agree that msession is better than using MySQL or PostgreSQL as a session manager. However, most people who use PHP on web farms already have some sort of database set up, so it seems logical to me to be able to use it for storing sessions. MySQL actually

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like

2002-05-29 Thread mlwmohawk
Steve Meyers wrote: Well, you didn't try it with MySQL, which is significantly faster than Oracle and Postgres for most stuff. In any case, I agree that msession is probably a better solution -- I just think that having built-in MySQL session support would be a good thing for PHP.

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like

2002-05-29 Thread mlwmohawk
[EMAIL PROTECTED] wrote: MySQL's table locking during update pretty much make sure that performance will degrade under heavy load with many connections. It's not actually as bad as you think. With a table like this, the table locking actually has a very minimal effect on it. In

Re: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-25 Thread Andi Gutmans
At 10:20 25/05/2002 -0400, [EMAIL PROTECTED] wrote: I kind of went off in a huff yesterday with the whole PECL/pear issue with msession, it's over and lets move on. I did, however, want to explain *why* I think msession should be in the main code. In *big* websites, you need multiple web servers

RE: [PHP-DEV] PHP web farms (i.e. why msession or something like it)

2002-05-25 Thread James Cox
These topics usually don't interest the average PHP developer - why keep it in the same manual, then? What do you think about this? +1 - Maybe even consider adding to part 2 some documentation on developing PHP itself. Right now, one must read the few files on the Zend API, some coding