[ic] Serving the images from a database
konsult at sebab.se
Thu May 6 03:18:03 EDT 2004
Well, the previous mail stated that it would be easiest to intercept
the http 404 requests and place a copy from the db onto the filesystem
to serve from, thus the image would be resized once, and it would only
be served once from the db. No 'on the fly' rescaling has been in the
planning :-) ..
It's mainly to get a single place to hold all your data, thus from your
ERP or similar system you can have all the data for the webshop in the
database and set up a couple of simple forms to handle the webshop daily
chores. Now when replicating to the database on the webserver you only
have to keep track of some little things to get this setup to run, (
like REALLY HARD and ANNOYING ISSUES actually but little things sounded
So it's for the integration of interchange with an ERP system.
/ Lars Segerlund.
> Lars Segerlund wrote:
>> There is another reson, and that is to be able to rescale/resize the
>> images for serving, ( thus ensuring that you get a decent bandwidth
>> usage ).
> Point one about resizing images:
> There are better ways to increase bandwidth usage than
> converting/resizing an image every time someone needs to fetch it. If
> you're planning on doing this then it doesn't much matter where the
> image is stored, the resizing operation itself takes up a lot of CPU
> time and you'll find your server grinding to a halt overnight. My
> experience says to do whatever resizing you need to do once. Either
> when the image is uploaded initially, or when it is first requested in
> that size and store multiple copies of the image in whatever different
> sizes you need on your webserver. Then you won't get a major cpu
> drain by having your server working overtime resizing images all the
> time but you will still get the benefit of smaller images where
> they're wanted.
> Point two about serving images from a db as opposed to off the
> Web servers are designed to be very fast at serving up static files
> off the filesystem. If you throw in an application layer in between
> such as what is needed to fetch an image stored in a db then you're
> slowing the process down and costing extra cpu time. it's great to
> store dynamic content in your db, but for static content such as
> images it's way better imo to store it in the filesystem and let the
> webserver do what it does best, fast serving up of static files.
> Anyways, my two cents,
> interchange-users mailing list
> interchange-users at icdevgroup.org
More information about the interchange-users