Quote:
Originally Posted by StupidScript
Boy. Looking at the site is a little mind-boggling. How many images are you expecting to deliver with each request? How 'big' will your canvas get?
IMHO, your least-resource-intensive method for continuing to develop this site would be to change from file-based to a blobbed-database structure. (a) This would immediately overcome the caching problem you describe, as each image would be drawn from a live database on demand with each request and (b) a few connections to the database per visitor would be a lot less "spendy" for the server than multiple http connections per visitor, which would bog things down pretty quickly when your traffic levels get high enough.
That project is going to push your resources to the max, sooner or later, regardless of which delivery method you choose. There's lots of big images in there, and even from my T3 connection it took awhile to fully load.
|
Hi,
Thanks for your feedback. I've been thinking about the db solution and it just seems very counter intuitive.
If the images are stored as Blobs, then, as you suggested, every pageview will force all that data to be sent to the browser, whereas if the images are cached, only the first time is all the data transfered to the client. subsequent visits will use the cached images UNTIL they expire. And that's what I was essentially asking how to do, force a longer than default expiration date.
"T3 connection it took awhile to fully load." Was it better the 2nd time you visited? I think hitting refresh, on some browsers, it forces a 'get all' regardless of what's cached, fyi.
The canvas will grow as large as possible. The project is essentially infinite, technical challenges aside.
One idea I had was to develop a google-maps like interface, where it loads new images as they are scrolled to towards them, but that's a bit beyond my current coding abilities.