mlwmohawk wrote:

> On Friday 21 December 2001 10:45 pm, Yasuo Ohgaki wrote:
> 
>>>>I was thinking about a PostgreSQL session manager. How is that going to
>>>>
>>>work? IMHO PostgreSQL (currently) is completely wrong for such a task.
>>>
>>I'm well aware of the issue you mentioned :)
>>
>>
>>>PostgreSQL has one real behavior problem. Updates act as if you do a
>>>delete then an insert, i.e. for transactional isolation, an updated row
>>>is added new, and the old one is marked as deleted. Sessions are all
>>>about updates, and any really active server cluster will expose
>>>PostgreSQL's worst behavior.
>>>
>>I agree. It will slows down thing a *LOT*.
>>
>>But it's faster than files save handler with proper
>>
>>administration, I suppose.
>>
> 
> I actually doubt it it will be. An insert into a database like PostgreSQL has 
> a lot more overhead than just the basic file manipulation.


Both I and you could be wrong :)
File system like Ext2, uses liner search for dir entry and dir
operation is atomic in OS. This is a lot of overheads.
However, newer FS like ReiserFS/XFS/Ext3 uses Btree for dir
entry that helps a lot.

PostgreSQL is using MVCC. Therefore, it could be faster for
many session data. It also can share session data with multiple
web servers.

Anyone care to take benchmarks?
(You need to wait a little more, since session module needed
to be changed to work with pgsql session save handler)

> 
> 
>>>After any serious usage, you will need to vacuum the table. In 7.1, that
>>>will lock the table and render the system unusable for a few minutes.
>>>When 7.2 is released, vacuum will not lock the table, but you have to
>>>have it running on a constant basis.
>>>
>>That's true. Users! you *MUST* run vacuum! As we mentioned, db like
>>session will slow things down a *lot* without vacuum!
>>
> 
> Yea, at my company we currently use Oracle for session management. I will be 
> trying to use msession as time goes on, but there is so much code to change. 
> 
> Oddly enough, it is because of PostgreSQL's limitations that I resurrected 
> some code I was working on for beowulf clusters, for msession.
> 
> The problem of coherent data and syncronization in a beowulf cluster and a 
> web farm are almost identical.


:)

 
> 
>>>The only thing I can think of is using the large object interface, and
>>>storing the unstructured PHP session data as a large object. It may not
>>>be as fast as regular SQL, but that may eliminate the update problem.
>>>
>>I have to check current implementaion of text/bytea type.
>>It may be as efficient as large object now. (I think it is, isn't it?)
>>Thanks for pointing it out. :) I might add your suggestion to
>>my ToDo list.
>>
> 
> The reason I suggest the large object interface is that I think you can 
> update the unstructured PHP session data string into a large object without 
> causing the row to be updated by PostgreSQL.  
> 
> This could cut down a lot of row updates, and performance may not degenerate 
> as fast.


Thanks.
I'll check about it.

 
>>BTW, users must vacuume constant basis still! Even I make use
>>of large object.
>>
>>The benefit of using pgsql session save handler is users can
>>add more fields to session record as user needs.
>>User can use standard I/F (i.e. SQL) I think some people
>>will like it, even if it is not as fast as msession ;)
>>
> 
> msession is pretty good, but it is not a SQL database. I totally understand 
> your objective. I was going to write a PostgreSQL based session manager, but 
> I came to the conclusion that PG isn't ready for it yet. I would love to be 
> proven wrong. I think PostgreSQL is great.


I like it too. That's why I wrote session save handler for it :)


> One more interesting msession twist, after coming to the conclusion that PG 
> wouldn't work, I wrote a set of functions for PostgreSQL first. Then, as I 
> was writing the session handler for PostgreSQL, I just figured I'd write it 
> to talk to msession directly.
> 
> The API exists, in PostgreSQL, to join against msession data in an msession 
> session. 


That's great! I'll check your code!!

> 
>>Besides, PostgreSQL limitations are really large,
>>it good for DoS attack or keeping session for a long time, too.
>>
> 
> Believe me, I'm not trying to sell you on msession in any way. You are 
> heading down a road I traveled about 6-8 months ago, and i'm ust trying to be 
> helpful. If you need anything, including me to shut up, just let me know.

I know you're nice person :) (I really mean)

-- 
Yasuo Ohgaki


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to