> -----Original Message----- > From: Steven van der Vegt [mailto:[email protected]] > Sent: Thursday, December 23, 2010 6:15 AM > To: [email protected] > Subject: [Pound Mailing List] RE: Website stalls every 60 seconds > > Hi Joe, > > Thanks for your quick and careful response! A few things that came to > mind: > > > I guess what you're really looking for is a read/write locking > system. > That's something I had in mind too. This will be a speedup in general > since all the read threads wouldn't be waiting on each other anymore.
...and it won't require any additional libraries, which will make Robert happy. > > Maybe instead of calling delete session it could create a temporary > array or linked list to save the nodes that need to be deleted and then > delete them in one shot... > Great suggestion. Like a static array of n elements. If the array is > full: lock -> delete -> unlock. If there are any unchecked elements > left, continue checking and deleting. I was thinking more like if the array is full, stop looking for more, lock delete and unlock. It's just going to find the rest in the next poll anyway. Then you don't have to worry about read/write contention either, since pthreads doesn't have a "upgrade me from read to write" call you'll probably have to release the read lock to obtain the write. (which will need to block until all read locks release) Once you do that and start deleting, or even inserts from other threads occur, the rest of the tree's structure from the previous iteration might not be valid anymore. (Especially if you don't set down_load=0 before delete, which you would no longer have to do, because tree shrinking would be fine. But it would invalidate the iterator.) I'm making some assumptions about the implementation of lh_doall but I would hope it's implemented that way. :) As we've already determined it's not thread safe in itself. > > What concerns me more efficiency-wise is the method of deletion... > Since the hashtable is a black box, we can't remove the in-place > node... the tree traversal has already located the node we want to > remove, and once we do our comparison, we have to do lh_delete which > will go through the table and locate it all over again. Depending on > how good the hash is and how many collisions you have that could be > significant. > > That is a waste of recourses indeed, but since the blackbox principle, > I don't see a way around it except for taking over some responsibility > of the lhash, which is somewhat "not done". However, the lhash code > hasn't changed within 12 years or so... Pound used to have its own linked list implementation for sessions (back in the 2.2 or 2.0 days) but I'd agree it was a logical move to lhash. You're right, there probably isn't much we can do there other than make sure the atomic section is as small as possible. > > It could mean that in your case t_hash isn't returning significantly > different hash values. > I will dig into that. For now the standard lhash lh_strhash function is > used. If the values suggest a lot of hash collisions take place, is MD5 > a good alternative? The hash function is actually provided in config.c with the call to lh_new... There's a t_hash function in the code there with a comment based on "fmv". Hashing calculations will be used on every request... From looking at t_hash it's probably more efficient than Md5 would be... That might cause other speed issues. But, for instance, if your hash keys are already long values (like jsessionids are like guids) maybe just hex string -> long would work and rely on the backend to handle uniqueness. Guids are longer than 32bits but I don't think the collision stats on that would be too bad. > > What type of data is in the cookie? Is it something like jsessionid? > How long is your TTL? > The cookie values are pretty basic, they only contain hashkeys. TTL is > set on 20 minutes. Seems to jive with above. > Would you all be interested if I look into the delete-all-at-once and > the readers-writers-lock? I will admit I'm intrigued and have been considering taking a stab at it myself. However you have the test bed already in place so yeah, I'd love to see what you come up with. Take care! Joe -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
