Caching DB queries amongst multiple httpd child processes
Does anyone have any experience in using IPC shared memory or similar in caching data amongst multiple httpd daemons ? We run a large-ish database dependent site, with a mysql daemon serving many hundreds of requests a minute. While we are currently caching SQL query results on a per-process basis, it would be nice to share this ability across the server as a whole. I've played with IPC::Shareable and IPC::ShareLite, but both seem to be a little unreliable - unsurprising as both modules are currently still under development. Our platform is a combination of FreeBSD and Solaris servers - speaking of which, has anyone taken this one step further again and cached SQL results amongst multiple web servers ? Thanks in advance, Peter Skipworth -- .-. | Peter SkipworthPh: 03 9897 1121 | | Senior Programmer Mob: 0417 013 292 | | realestate.com.au [EMAIL PROTECTED] | `-'
Re: Caching DB queries amongst multiple httpd child processes
Peter Skipworth wrote: Does anyone have any experience in using IPC shared memory or similar in caching data amongst multiple httpd daemons ? We run a large-ish database dependent site, with a mysql daemon serving many hundreds of requests a minute. While we are currently caching SQL query results on a per-process basis, it would be nice to share this ability across the server as a whole. I've played with IPC::Shareable and IPC::ShareLite, but both seem to be a little unreliable - unsurprising as both modules are currently still under development. Our platform is a combination of FreeBSD and Solaris servers - speaking of which, has anyone taken this one step further again and cached SQL results amongst multiple web servers ? I've written my own solution to this, called Tie::MmapCache, which implements an LRU cache of data in a memory mapped file, which can be shared by an arbitrary number of processes. Unfortunately, it's not publically available yet, but I hope to get it released soon. -- Peter Haworth [EMAIL PROTECTED] "The warts in a language tend to be more orthogonal than the features" -- Larry Wall, at the Perl Conference 2.0
Re: Caching DB queries amongst multiple httpd child processes
On Thu, 3 Feb 2000, Peter Skipworth wrote: Does anyone have any experience in using IPC shared memory or similar in caching data amongst multiple httpd daemons ? Well, I just released IPC::Cache version 0.02 to CPAN. Two major caveats, however -- first, it is not currently in production on our site (www.eziba.com) and won't be for another week or two. Second, it relies on IPC::ShareLite as a backend. However, it does offer a very straightforward interface, and attempts to manage the memory segments and clean up after them. We are running Linux 2.2 on the front end, btw, and that may account for why ShareLite seems rather reliable for us. I'd love it if you could download it and let me know it works for you. We are planning on maintaining this, and would appreciate any feedback you can give about how to improve it. You can get IPC::Cache here: http://www.cpan.org/modules/by-module/IPC/IPC-Cache-0.02.tar.gz -DeWitt
Re: Caching DB queries amongst multiple httpd child processes
At 03:33 PM 2/3/00 +1100, Peter Skipworth wrote: Does anyone have any experience in using IPC shared memory or similar in caching data amongst multiple httpd daemons ? We run a large-ish database dependent site, with a mysql daemon serving many hundreds of requests a minute. While we are currently caching SQL query results on a per-process basis, it would be nice to share this ability across the server as a whole. I've played with IPC::Shareable and IPC::ShareLite, but both seem to be a little unreliable - unsurprising as both modules are currently still under development. Our platform is a combination of FreeBSD and Solaris servers - speaking of which, has anyone taken this one step further again and cached SQL results amongst multiple web servers ? We looked at this, as we have a busy multiple web server environment and are planning to use Apache::Session + Mysql to manage session state. Although per-host caching in shared memory or whatever seemed desirable on paper, the complexities of ensuring that cache entries are not invalid due to an update on another server are major. When we set up a testbed to benchmark Mysql for this project, the time taken to retrieve or update a session state record across the network over an established connection to our Mysql host (Sparc 333 mhz Ultra 5/Solaris 2.6 with lots of memory) was so small (5-7 ms including LOCK/UNLOCK TABLE commands where needed) that we didn't pursue per host caches any further. Clearly, YMMV depending on the hardware you have available. - Simon Thanks in advance, Peter Skipworth -- .-. | Peter SkipworthPh: 03 9897 1121 | | Senior Programmer Mob: 0417 013 292 | | realestate.com.au [EMAIL PROTECTED] | `-' - Simon Rosenthal ([EMAIL PROTECTED]) Web Systems Architect Northern Light Technology 222 Third Street, Cambridge MA 02142 Phone: (617)577-2796 : URL: http://www.northernlight.com "Northern Light - Just what you've been searching for"
