> [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 <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
