Reputation: 21
I have to do a design decision for deployment here is the requirement
My Questions:
Thanks in advance
Amit
Upvotes: 2
Views: 314
Reputation: 156238
At a small enough scale, it doesn't matter. If your workload is a few dozen employees using an internal web service that doesn't require a lot of resources per request, then do whatever you can deploy quickly. that might mean serving static content through a handler in your web-app, on a single server.
When you start to scale up, things that didn't matter before become noticeable.
The first thing that becomes noticeable on the above configuration (static content handled by the web-app) is that pages take a lot longer to load. That's because only one part of the page is actually dynamic, the HTML itself, but images, javascript, css, and whatever other odds and ends your page includes are also following the same lifecycle.
One thing you can do to improve things is to serve the static content intelligently in your handler to take advantage of caches and proxy servers, by setting the Expires
and ETag
headers, and returning 304 Not Modified
when appropriate.
But that's all a static web server does already. Plus a static web server can be significantly better optimized at that specific workload. When you really start to scale up, shifting this workload to another host, so that the app server never even sees it, is one of the easiest ways to extract more performance from your web-app for very little cost.
Upvotes: 2
Reputation: 39490
Yes, this is an appropriate approach. By putting the static content on the (static content) web server as opposed to the app server, it reduces the potential load on the app server; web requests for dynamic content can be cleanly passed through to the app server with nearly no effort.
Upvotes: 1