I am disagreeing with *serving* images directly from the database. I'm suggesting the serve path to be:
Browser <img src="*.gif"> Request -> IIS -> Image File -> IIS -> Browser Response rather than Browser <img src="*.cfm"> Request -> IIS -> ColdFusion Server Request -> Database Driver -> Row Retrieval -> Pointer Evaluation -> Binary Retrieval From Separate Device On Disk -> Database Driver -> ColdFusion Server Binary Conversion -> IIS -> Browser Response And I'm suggesting that this can be accomplished by either directly updating a remote shared storage system via FTP assisted by some automated process, or if replication is a requirement then pre-processing those binaries into image files so they can be served directly from IIS. Respectfully, Adam Phillip Churvis Certified Advanced ColdFusion MX 7 Developer BlueDragon Alliance Founding Committee Get advanced intensive Master-level training in C# & ASP.NET 2.0 for ColdFusion Developers at ProductivityEnhancement.com ----- Original Message ----- From: Dinner To: CF-Community Sent: Monday, February 19, 2007 2:35 PM Subject: Re: Storing images in DB. I'm with Nick on this one. I love my pictures in me DB! We've got a pure DB server, with a dedicated connection to our CF box. With 20 people hitting it at once, it still served up pages pretty damn fast. Perhaps the webswerver itself was doing some caching-- there's this whole "new" technology 'round that, neh? Least, sure looks like Apache's added a bunch of mem/disk caching. PITA when you don't want something cached, but I'd struggle with that to have most everything else be pretty fast. It's pretty easy to write your own cache system (it doesn't even need to be that sophisticated-- you see if an image is there, if it's current, and if not, grab the new one from the cache), if you don't want to rely on one of the many caching options available (or just pull from the DB). Anything dealing with "load" should be pretty heavily cached anyways, right? I mean, I've seen it to where people generate a whole static site, off the "dynamic" content-- just to keep stuff "fast". Not a bad idea. But anyways, having all your data in one place is freaking awesome, and it's really freaking awesome when you get into the whole "my web root has only two files-- Application and Index". See, when you do a setup like that, the only "hole" is that you can't use mappings to serve web content. Thus, you need a central "resource" location, be it a replicated directory (so all instances in the cluster have access to the same images) or a dedicated servlet type thing. ;-) Bah- when you get into heavy load, you end up having specialized servers-- can you imagine a server just for images? Yeah, it happens, and makes sense. Might as well be set up for it ahead of time. Either way (if you store the images in a DB or not), I'd suggest a central location for things like images or word docs, etc.- If you're still doing the whole /images bit-- mixing your images/resource docs in with the code tree, you'll be in for a hell of a re-vamp when you move away from that. If you do. I try to think about what will happen, when we move to the cluster, ahead of time. Considering I allow users to upload images, files, etc.-- that's a lot of stuff for the servers to replicate (if you do it the old scool "hard file" (vs. "soft", cachey type stuff) way)... One of the nice things about the DB and "loose" location of files, is it avoids (a little bit) the security hole of allowing people to write files directly to the filesystem. I'd love to store all of it in memory, really. Yes, the REAL solution is a freaking ton of RAM. A metric ton load of it. :D On 2/19/07, Adam Churvis <[EMAIL PROTECTED]> wrote: > > Nick, > > Have you ever tried this *under load* with either a large number of images > on a single web page, a single large image, or a combination of these? It > all seems about the same on the work bench, but it's a whole different story > under load, which is all that really matters. This is why Microsoft itself > employs sophisticated caching schemes to eliminate the need to touch the > database for binaries any more than it absolutely has to. > > Also, look at every single step of what *actually* happens when you > retrieve binary data from the database, serve it, and convert it. You're > being a bit too simplistic when you mention the pointer stored in the table, > as if that somehow makes it like a direct file retrieval from disk. There's > a lot of work that's done to make this happen, and it does make a difference > that you'll notice under a realistic load. > > Respectfully, > > Adam Phillip Churvis > Certified Advanced ColdFusion MX 7 Developer > BlueDragon Alliance Founding Committee > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 by Adobe® Dyncamically transform webcontent into Adobe PDF with new ColdFusion MX7. Free Trial. http://www.adobe.com/products/coldfusion Archive: http://www.houseoffusion.com/groups/CF-Community/message.cfm/messageid:228361 Subscription: http://www.houseoffusion.com/groups/CF-Community/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.5
