On Thu, Jan 16, 2003 at 06:05:30AM -0600, Christopher L. Everett wrote: > > Do AxKit and PageKit pay such close attention to caching because XML > processing is so deadly slow that one doesn't have a hope of reasonable > response times on a fast but lightly loaded server otherwise? Or is > it because even a fast server would quickly be on its knees under > anything more than a light load?
It really pays off to do any steps that will increase the throughput. And AxKit is well suited for caching because it has clear layers and interfaces between them. So I see AxKit doing caching not only to get the performance, but also "just because it can". You cannot do the caching easily with more dirty approaches. > With a MVC type architecture, would it make sense to have the Model > objects maintain the XML related to the content I want to serve as > static files so that a simple stat of the appropriate XML file tells > me if my cached HTML document is out of date? Well, AxKit uses filesystem cache, doesn't it? It really depends on how much precission you need to achieve. If you run a website that lists cinema programs, it's just fine that your public will see the updated pages after five minutes, not immediatelly after they were changed by the data manager. Then you can really go with simply timing out the items in the cache. If you need to do something more real-time, you might prefer the push approach of MVC (because pull involves too much processing anyway, as you have said), and then you have a small problem with MySQL. As it lacks trigger support, you will have to send the push invalidation from you applications. Which might or might not be a problem, it depends on how many of them you have. -- ------------------------------------------------------------------------ Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/ ... all of these signs saying sorry but we're closed ... ------------------------------------------------------------------------
