in reply to Ways of caching
I've done something very similar in my calendar application and it seems to work really well. It's not a high-load application, so my primary motivation was to improve the response time by cutting off dynamic calendar view computations when there are no changes. I get about 50% improvement in response time when pages are viewed. The downside is that there is a slow down when pages are updated, but I figured the users of my application would be okay with a slight delay when they click "Save Changes" in exchange for faster loading pages when viewing. When users make updates to one of the pages I just replace the corresponding text file in cache. I do take concurrency issues into account, so I use flock() whenever a cache file is accessed for update. At the same time if the same file is requested from the cache while it's being written to, I detect that and return a dynamically generated page instead. Whenever more than one page is affected by a change, the application updates the page that is currently viewed first, returns that page to the user and then forks a separate process to finish updating other affected pages.
I could show you some source code if you're interested.
Alex
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Ways of caching
by kiat (Vicar) on Jul 07, 2004 at 11:53 UTC |