I've got a simple question and also hear others' encounters regarding the best idea method to replicate images across multiple hosts.
I've determined that storing images within the database after which using database replication over multiple hosts would lead to maximum availability.
Worries I've using the filesystem may be the difficulty synchronising the pictures (e.g I'm not going 5 servers all striking exactly the same server for images!).
Now, the only real concerns I've with storing images within the database may be the extra queries striking the database and also the extra handling i'd have to set up devote apache basically wanted 'virtual' image links to suggest to database records. (e.g AddHandler)
So far as my understanding goes:
- For those who have a script serving in the images: Each image would need a database call.
- Should you display the pictures inline as binary data: That could be completed in just one database call.
- To supply exterior / linkable images you would need to give a addHandler for that extension you desire to 'fake' and point it for your scripting language (e.g php, asp).
I would have skipped something, but I am curious if anybody has much better ideas?
Edit: Tom has recommended using mod_rewrite in order to save utilizing an AddHandler, I've recognized like a suggested means to fix the AddHandler problem however don't yet seem like I've got a complete solution yet so please, please, keep responding to )
A couple of have recommended using lighttpd over Apache. How different would be the ISAPI modules for lighttpd?
Should you store images within the database, you are taking an additional database hit plus you lose the innate caching/file serving optimizations inside your web server. Apache assists a static image considerably faster than PHP can keep it in check.
Within our large application conditions, we consume to 4 groupings:
- Application server cluster
- Web service/data service cluster
- Static resource (image, documents, multi-media) cluster
- Database cluster
You would be surprised just how much traffic a static resource server are designed for. Becasue it is not necessarily computing (no application logic), an answer could be enhanced constantly. Should you opt for another static resource cluster, additionally you expose yourself to alter exactly that part of your architecture. For example, in certain benchmarks lighttpd is even faster at serving static assets than apache. For those who have another cluster, you are able to improve your http server there without altering other things inside your application atmosphere.
I'd begin with a couple-machine static resource cluster and find out how that works. That's another advantage of separating functions - you are able to scale out only where you really need it. So far as syncing files, have a look at existing file synchronization tools versus moving your personal. You might find something which does the thing you need without needing to write a type of code.