On Apr 6, 2007, at 4:58 PM, Perrin Harkins wrote:
Although that sounds reasonable, when I've tried to test it my results
have been the opposite -- storage speed really matters and locking
doesn't matter much at all.
I did some benchmarking of various cache modules for a talk I gave at
OSCON in 2002. At the time, I found that the number of HTTP processes
trying to write to the cache didn't change the overall performance
picture, i.e. the ones that used the fastest storage mechanisms
clearly won both in read-only and write-heavy situtations. It might
be because the locks are held for shorter periods of time, or that the
number of mod_perl processes competing for locks is not all that high,
or possibly just a lame test, but I couldn't get the locking to
register as significant.
Massive grain of salt not included.
Honestly -- I'd trust your tests over mine on any given day.
On my tests I showed nearly no difference -- but I was guaging db
call heavy pages. .003 vs .0003 seconds made no real difference
outside a margin of error when the avg page execution was around .03.
i'm not hitting any performance bottlenecks right now, so I just use
memcached+pg failover for everything. it takes 2 minutes to code ,
scales, and works well enough.
I'm helping a friend build a social bookmarking site this weekend - I
might give bdb a try for some sessions , because the machine its
going on isn't clustered like the rest i have.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
