В достаточно малых масштабах это не имеет значения. Если ваша рабочая нагрузка составляет несколько десятков сотрудников, использующих внутреннюю веб-службу, для которой не требуется много ресурсов для каждого запроса, выполните все, что вы можете быстро развернуть. это может означать обслуживание статического контента через обработчик вашего веб-приложения на одном сервере.
Когда вы начинаете увеличиваться, вещи, которые не имеют значения, становятся заметными.
Первое, что становится заметным в приведенной выше конфигурации (статический контент, обрабатываемый веб-приложением), заключается в том, что страницы занимают намного больше времени для загрузки. Это потому, что только одна часть страницы на самом деле динамическая, сам HTML, но изображения, javascript, css и любые другие варианты и цели вашей страницы также следуют одному и тому же жизненному циклу.
Одна вещь, которую вы можете сделать, чтобы улучшить положение вещей, чтобы служить статическое содержимое разумно в обработчике, чтобы воспользоваться кэшей и прокси-серверов, установив Expires и ETag заголовки, и возвращение 304 Not Modified при необходимости.
Но это все, что делает статический веб-сервер. Кроме того, статический веб-сервер может быть значительно оптимизирован при этой конкретной рабочей нагрузке. Когда вы действительно начинаете масштабироваться, перенося эту рабочую нагрузку на другой хост, чтобы сервер приложений никогда не видел ее, это один из самых простых способов извлечь большую производительность из вашего веб-приложения за очень небольшую стоимость.
Спасибо McWafflestix. Не могли бы вы предоставить некоторый указатель для разных подходов для этого. – user508657