[ic] Serving the images from a database

[Lars Segerlund]

 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 
better).

 So it's for the integration of interchange with an ERP system.

 / Lars Segerlund.

Peter wrote:

> 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 
> filesystem:
>
> 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,
>
> Peter
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>
>