Also if these images are loaded more than once by a given user you should also let the browser cache them. Set content experation for your images as the web server serves them to the user. This will greatly improve performance also. As the webbroweer will not have to down load the image again it will just use the cache. You might also check your web server cache settings. IIS and apache can cache static content in memory for faster response. You might look a cache server as Nat mentioned. If you have a lot of static content that need to be server(s) you might adjust things so a specific server serves those items so all of its ram can be dedicated cacheing them.
On 10/7/05, Nando <[EMAIL PROTECTED]> wrote: > Hi Barney, > > Thanks for your explanation. Got it ... the WEB server / OS should be > handling/caching the images, not CF, because CF isn't processing them to > begin with. Sounds like i'd better widen my approach out a little more. > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Behalf Of Barney Boisvert > >Sent: Thursday, October 06, 2005 11:50 PM > >To: [email protected] > >Subject: Re: [CFCDev] ImageCache experiments > > > > > >I definitely think your problem is something aside from disk access. > >Have you monitored the reads it's doing under load and confirmed that > >it's really at it's max? Any decent filesystem will do in-memory > >caching of commonly requested blocks, so unless you're hitting a wide > >variety of disk-based content, you shouldn't be hitting the disks at > >all. > > > >Do you have trusted cache enabled in CF and your CF templates on the > >same physical device as the graphics in question? If you do, then > >it's definitely not a disk issue. > > > >Bottom line, I'd make sure that's really your problem before you bury > >your CF server in a massive number of requests, and completely > >slaughter it's ability to serve real pages. > > > >cheers, > >barneyb > > > >On 10/6/05, Nando <[EMAIL PROTECTED]> wrote: > >> So i should move the cfcontent out of the getImage method, and > >return a struct instead with the image type and image data. (or do > >i really need different type attribute values for the different > >image types?) It's working with the cfoutput tags, but maybe > >that's not as efficient as it could be. > >> > >> The reason i'm trying to serve these images from memory is > >because the interface is very rich in graphics - and it seems the > >performance bottleneck might be at the disk access point. There's > >plenty of memory and enough cpu available, and when it bogs down, > >it's the graphics that are coming in one by one, 15, 20 seconds > >apart. My reasoning is that all threads could have more or less > >instant read access to memory, but they'd need to que for access > >to the disk. Does that make sense? > >> > >> thanks for your help! > >> Nando > >> > > > >-- > >Barney Boisvert > >[EMAIL PROTECTED] > >360.319.6145 > >http://www.barneyb.com/ > > > >Got Gmail? I have 100 invites. > >bnqNrzuqq{vryuy~z > >o {qvyF?j jry rzjnj} > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
