On Thu, 24 Feb 2005 10:25:14 -0500, Bryan F. Hogan <[EMAIL PROTECTED]> wrote: > > While I'm not advocating it, running purely with database queries > > makes nearly as much sense (at least, up to a point) -- since both > > ColdFusion and the database are caching the disk-based data into > > memory. Using included files and having Apache/etc do the caching is > > analogous. In both cases, the servers are going to try and minimize > > disk i/o, so you'll end up with data in memory most of the time > > anyhow. > > This is all fine except for large applications with many articles. For > example I have an Intranet for lawyers that has 600,000 articles. There is > no way I'm going to query the db every time one of those articles are > accessed. First because they are long-winded and second because they are > accessed frequently.
Actually, I think you missed part of the point. Regardless of whether the article is data in a database or a text file sitting on a disk, the amount of disk I/O to get those blocks into memory is the same order of magnitude (db page size and fragmentation vs os block size and fragmentation probably plays a role, but still should be same order of magnitude). Plus your query is probably only going to the app server (ColdFusion's query cache) or to the database's memory (cached database pages) and not the disk directly if it's a frequently used item -- frequent use is exactly why relying on the inherent caching in the lower-level components is useful! The database option requires a little more *processor* overhead (for the database and the app server) but the slow step is the disk i/o. And that difference may be moot if you're using some sort of compression on the web server (e.g. mod_deflate, mod_gzip, or the IIS equivalent filters) which also requires overhead If either your web server cache or your database cache (or you app server cache for that matter) can hold the entire collection, the point is pretty moot about where it lives -- though I'd personally go for the disk files. Legal documents -- maybe 4MB each? 2.5 GB of memory puts a big dent in that and isn't very expensive, relatively speaking. So to be safe, a server with 4 GB of RAM could run the collection (or at least the hottest part of the collection) in main memory -- regardless of whether it's web server, app server, or database server. My real vote would probably be RAM disk with Apache to serve it up... or MySQL 4.1 with the query cache set to the size of the database :) Plus I'd make sure to use the meta headers on the resulting pages to prevent duplicate downloads. Of course there is a hit if you have to completely rebuild the collection (catastrophic disk failure on web server) but that's probably on the order of a database restore. Of course I like playing with 10-100GB MySQL data warehouses, so I'm biased :) -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:196307 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
