• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Image Server for WebApp... questions about how to serve images

T

TechBoyJK

Lifer
I'm building an app, and I'm trying to decide on the best way to manage hosting photos that would be uploaded.

The app is hosted on a CentOS vm named WWW01.

My current plan is to have a standalone CentOS box called 'IMAGES01' on the same private network with a folder /images shared via NFS and mounted as /images01 on the webserver (WWW01). With that, any uploads through the webapp will end up on the image server.

In order to serve the images, I'm trying to decide between hosting them back through the webserver, or hosting them directly from the imageserver. It seems like it would be more efficient to use apache to host the images directly off the image server.

Thoughts?
 
debian0001 said:
Wouldn't it be better to have it hosted on the same server? Seems overkill to have 2.
Click to expand...

Good question. Let me explain why I'm planning things this way.

It's for growth. There will be multiple web servers for load and redundancy.

The app is coded to allow for multiple image servers as well. By keeping the images on a separate server, images uploaded through the app don't need to be reconciled among the different web servers. They will all hit a single, central image repository. And I can also have multiple repositories by just setting up a new image server (IMAGES02, IMAGES03). My app will keep track of which imageserver an image is on, and include that info when retrieving and publishing the image.

aka. I could have 20 different instances of the webapp running on the cloud, and if I hosted directly, they'd all need to have copies of the images and keep it in sync. That's 20 copies of each image. That'd actually be overkill.

Make sense?
 
Last edited:
Serving files off NFS doesn't seem like a good idea to me. That just means both servers have to do work. I'd think you'd want to serve the files directly off separate servers. At some point, you might want to move the files to a Content Delivery Network, or CDN, and then you'd definitely want the files on separate servers.
 
Ken g6 said:
Serving files off NFS doesn't seem like a good idea to me. That just means both servers have to do work. I'd think you'd want to serve the files directly off separate servers. At some point, you might want to move the files to a Content Delivery Network, or CDN, and then you'd definitely want the files on separate servers.
Click to expand...

I have to agree with this. You are only introducing more load on the app server by making it serve both the http request and mounting/using the NFS share. I guess the work of integrating whatever access control between the app server and the content server could be avoided with the NFS approach though.
 
If they are on the same physical machine serving over a share folder adds protocol overhead that just isn't needed. For instance if a VM vendor, or a personal cloud stack, might run virtual images off of iSCSI then there is no reason you 'd want to NFS between your vm's which are already running on top of another filesystem (hopefully zfs) which might already be implementing NFS.

HTTP static content is probably the best bet. Nginx it out.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top