File Server Approaches
I am working on building a file server that can take the load off the main website and serve images / files over the internet to a client.
The main goals of the file server are:
- Take the load off the main server that hosts the site
- Reuse the existing web server code base and avoid code / logic duplication for better support.
- Be scalable to increase downloads
- Hide real url download path from user
Keeping the above in mind, I could come up with two approaches. Presentation of a sequence diagram of the two approaches for ease of understanding [apologies for misused use of the sequence diagram]. None of the approaches will suit all of my goals.
Which of these approaches would you recommend considering my goals?
Is there a better third approach?
Some of the differences I could think of:
- Approach # 1 would result in duplicate BL code causing maintainability issues
- Approach # 2 would reuse code and centralize BL, reducing maintainability issues
- Approach # 1 would reduce network calls, while # 2 increased them
The concept of file servers, download scalability, bandwidth allocation have been there for a while. Please share your thoughts!
UPDATED:
Approach # 1 looks very appealing as it completely offloads the load from the main server. The only issue I have to deal with at # 1 is code duplication and maintainability issues. This could be overcome by having only one BL / DAC project containing the functionality needed for both the web service and the file server. And reference the assembly / library in your webserver and fileserver projects. There is now only one BL / DAC code to support and also avoids net calls in Approach # 2.
source to share
When sending images / files to the client, I am assuming you mean static css, js, etc. files.
In most cases, the simple solution is the best solution. Just host them on another server under a different subdomain, i.e. http://content.mydomain.com/img/xyz.jpg . You can host them in the datacenter on a dedicated server by providing your perforation (next to the base), you can load the URL balance and have 2+ servers in 2+ different datacenters, which will give you resilience and scalability.
You have the task of finding a replacement when promoting your site to live, to replace the dev / uat content paths with the realtime content outline (you only had to do this in css files as you could store paths for content used in aspx files for configuration data).
source to share