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

[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 correct the misinformation:

http://www.mysql.com/doc/S/E/SEC446.html

The difference is that in MySQL you don't have to use a table handler that 
supports referential integrity, row-level locking, or MVCC.  In a table 
that just handles sessions, that is probably preferable.

> PostgreSQL support transaction and row level lock,
> while MySQL supports lock or page level rocks. (3.x)
> Besides, MySQL manual states that it does not perform
> well when insert and update is concurrently performed.
> A-I 1.4 (which is the case for session management)
> 
As I mentioned, MySQL does support row-level locking, transactions, etc.  
Please people, let's stop spreading the FUD of yesteryear about MySQL.  In 
any case, the major performance hits for MyISAM tables in MySQL (which both 
of you seem to be referring to) come when you do selects that take a long 
time on tables that are updated a lot.  That isn't the case with a session 
table -- all selects are one well-indexed row.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 would be a good thing for PHP.
>
>You can easily port session pgsql for mysql.
>
>BTW, as far as my benchmarks on session pgsql and files
>handler, they are almost equal. I didn't benchmark
>in detail, but I doubt mysql could be much faster than
>PostgreSQL. Just my guess.

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


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 isn't too
>> bad, as long as you use HASH  (in-memory) tables.
>  
> That is where I disagree. At my last gig we used a combination of Oracle
> and PostgreSQL. The session management was a bigger Oracle hit than the
> rest of the site. It was horrible. It was partially some of this
> experience that encouraged me to do msession.
>  
> The msession daemon can be setup on a backend box and completely
> forgotten. No table space worries, no query optimizaton.
>  
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.

>>  
>> MySQL.  They weren't all serving the same content, but almost all of
>> them  were sharing a session.
>  
> How many session transactions did you get per second? (i.e. select session
> data, update/insert session data)
>  
> I would not suspect that MySQL could do this very well because it does not
> support NVCC and updates lock the entire table.

I have no idea -- I do know that we never had any troubles with the box 
that had the session database on it.

Incidentally, MySQL using InnoDB tables supports MVCC and row-level 
locking.  However, I suspect that in this case the InnoDB tables would 
actually be slower than the table-locking MyISAM tables.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 easy. Alas, the problems 
>> with PostgreSQL as a session manager are many. MySQL is just as bad, 
>> but for different reasons. :-) 
>>   
>> It is because the databases fall flat as session managers that I wrote 
>> msession in the first place. 
>>   
> 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 isn't too 
> bad, as long as you use HASH  (in-memory) tables. 
 
That is where I disagree. At my last gig we used a combination of Oracle and 
PostgreSQL. The session 
management was a bigger Oracle hit than the rest of the site. It was horrible. It was 
partially some of 
this experience that encouraged me to do msession. 
 
The msession daemon can be setup on a backend box and completely forgotten. No table 
space worries, no 
query optimizaton. 
 
>  
>>>   
>>> Right now I don't run any web farms, but I used to work for a company 
>>> with  125+ web servers, so I understand the problem. 
>>   
>> 125??!! All serving the same content? All maintaining a coherent 
>> environment? What did you use for session data? 
>  
> MySQL.  They weren't all serving the same content, but almost all of 
> them  were sharing a session. 
 
How many session transactions did you get per second? (i.e. select session data, 
update/insert session 
data) 
 
I would not suspect that MySQL could do this very well because it does not support 
NVCC and updates lock 
the entire table. 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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. Alas, the problems with
> PostgreSQL as a session manager are many. MySQL is just as bad, but for
> different reasons. :-)
>  
> It is because the databases fall flat as session managers that I wrote
> msession in the first place.
>  
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 isn't too bad, as long as you use HASH 
(in-memory) tables.

>>  
>> Right now I don't run any web farms, but I used to work for a company
>> with  125+ web servers, so I understand the problem.
>  
> 125??!! All serving the same content? All maintaining a coherent
> environment? What did you use for session data?

MySQL.  They weren't all serving the same content, but almost all of them 
were sharing a session.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 something like this should be 
>> mainstream, all components should in be in the PHP source tree, 
>> including the daemon. 
>>  
>  
> I personally think the best solution would be something like the 
> postgresql  session extension, except generalized to work with any (or 
> at least  several) databases.  Built-in MySQL session support is 
> definitely needed. 
 
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. 
Alas, the problems with 
PostgreSQL as a session manager are many. MySQL is just as bad, but for different 
reasons. :-) 
 
It is because the databases fall flat as session managers that I wrote msession in the 
first place. 
 
>  
> Right now I don't run any web farms, but I used to work for a company 
> with  125+ web servers, so I understand the problem. 
 
125??!! All serving the same content? All maintaining a coherent environment? What did 
you use for session 
data?  
 
 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 this should be
> mainstream, all components should in be in the PHP source tree, including
> the daemon.
> 

I personally think the best solution would be something like the postgresql 
session extension, except generalized to work with any (or at least 
several) databases.  Built-in MySQL session support is definitely needed.

Right now I don't run any web farms, but I used to work for a company with 
125+ web servers, so I understand the problem.

Steve Meyers

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 standards, subscribe to this list, and use the
> force (read the source) - not that this approach is all bad.
>
There are some musings to split the manual up, and make it more usefull,
ie -- allow extension developers the opportunity to manage their own
documentation, and have it built and integrated into the overall system...
So I think modularizing the doc system is a good idea.

 -- james


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 serving copies of the same
>data in a load balanced environment. The PHP session code, in its native
>state, can not manage this efficiently. You need some sort of external 
>session
>management system.
>
>Putting aside msession or SRM for the moment, the capability of linking
>multiple PHP web servers is vital. As one scans the PHP site, it is not
>immediately obvious how this is done, or that it can be done at all. You 
>have
>to do a bit of digging to figure out how to do it.
>
>I have worked as a software developer for almost 20 years now, and it has
>become obvious to me that people in charge of making technology decisions 
>are
>not as technically savvy as we would like or is often assumed. They NEED 
>to be
>spoon-fed. If they have to look for something, they will probably assume it
>does not exist and opt for the solutions that are marketed at them.
>
>Obviously I think msession is pretty good, but SRM works too.  Regardless of
>which, or even either, PHP needs to make an ?enterprise? statement.
>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.

I agree. I also think that a solution like msession should be pushed 
despite the work on SRM because many PHP programmers will not want to go in 
the SRM direction but will want a plug-and-play solution for the most 
common PHP 2-tier Apache <-> DB solution.


Andi


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php