Почему кэш статические файлы с Лаком, почему бы не передать
Вы включили автоматическое перенаправление из http://windstream.workterra.net кому: https://www.workterra.net/ на Вашем ISA MS httpd сервер. Укажите корректный URL перенаправления для решения этой проблемы.
У Varnish есть несколько преимуществ. Первое, что вы заметите, - это снижение нагрузки на внутренний сервер. Обычно путем кэширования содержимого, которое создается динамически, но редко изменяется (по сравнению с тем, как часто к нему обращаются). Если взять ваш пример Wordpress, большинство страниц, по-видимому, изменяются не очень часто, и существуют некоторые плагины, которые делают недействительным кеш-лак при изменении страницы (например, новая публикация, редактирование, комментарий и т. Д.). Следовательно, вы кешируете на неопределенный срок и аннулируете при изменении, что приводит к минимальной нагрузке на ваш внутренний сервер.
Несмотря на связанную статью, большинство людей предложит, что Varnish работает лучше, чем Nginx, при правильной настройке - хотя, (и Мне действительно не нравится это признавать) - мои собственные тесты, похоже, подтверждают, что nginx может обрабатывать статический файл быстрее, чем varnish (к счастью, я не t использовать для этого лак). Я думаю, что проблема в том, что если вы в конечном итоге используете Varnish, вы добавили дополнительный слой в свою настройку. Прохождение этого дополнительного уровня на внутренний сервер всегда будет медленнее, чем просто обслуживание непосредственно с внутреннего сервера - и именно поэтому разрешение Varnish кэшировать может быть быстрее - вы экономите шаг. Другое преимущество - наличие disk-io. Если вы настроите varnish для использования malloc, вы вообще не попадете на диск, что сделает его доступным для других процессов (и, как правило, ускорит процесс).
Я думаю, что потребуется лучший тест, чтобы действительно измерить производительность. При неоднократном запросе одного и того же файла запускаются кеши файловой системы, которые начинают смещать фокус с самих веб-серверов. Лучшим тестом было бы использовать осаду с несколькими тысячами случайных статических файлов (возможно, даже из журналов вашего сервера) для имитации реалистичного трафика. Возможно, однако, как вы упомянули, становится все более распространенным выгрузка статического контента в CDN, что означает, что Varnish, вероятно, не будет обслуживать его с самого начала (вы упомянули S3).
В реальном сценарии вы, скорее всего, расставите приоритеты по использованию памяти - в первую очередь, динамический контент, поскольку его создание наиболее затратно; затем небольшой статический контент (например, js / css) и, наконец, изображения - вы, вероятно, не стали бы кэшировать другие носители в памяти, если у вас нет действительно веской причины для этого. В этом случае, когда Varnish загружает файлы из памяти, а nginx загружает их с диска, Varnish, скорее всего, превзойдет nginx (обратите внимание, что кеши nginx предназначены только для проксирования и fastCGI, а те, по умолчанию основаны на диске - хотя можно использовать nginx с memcached).
(Мой быстрый - очень грубый, не заслуживающий доверия - тест показал, что nginx (direct) был самым быстрым - назовем его 100%, varnish (с malloc) был немного медленнее (около 150%), а nginx за лаком (с проходом) был самым медленным (около 250%). Это говорит само за себя - все или ничего - добавление дополнительного времени (и обработки) для связи с серверной частью просто означает, что если вы используете Varnish и у вас есть RAM, чтобы сэкономить, вы можете просто кэшировать все, что можете, и обслуживать его из Varnish вместо того, чтобы передавать обратно в nginx.)
varnish (с malloc) был немного медленнее (около 150%), а nginx за лаком (с pass) был самым медленным (около 250%). Это говорит само за себя - все или ничего - добавление дополнительного времени (и обработки) для связи с серверной частью просто предполагает, что если вы используете Varnish и у вас есть свободная оперативная память, вы можете просто кэшировать все, что можете, и обслуживать это из Varnish вместо передачи обратно в nginx.) varnish (с malloc) был немного медленнее (около 150%), а nginx за лаком (с pass) был самым медленным (около 250%). Это говорит само за себя - все или ничего - добавление дополнительного времени (и обработки) для связи с серверной частью просто предполагает, что если вы используете Varnish и у вас есть свободная оперативная память, вы можете просто кэшировать все, что можете, и обслуживать это из Varnish вместо передачи обратно в nginx.)I think you might be missing something.
By definition, dynamic files change. Typically, they change by doing some sort of database query that affects the content of the page being served up to the user. Therefore, you do not want to cache dynamic content. If you do, it simply becomes static content and most likely static content with incorrect content.
As a simple example, let's say you have a page with the logged in user's username at the top of the page. Each time that page is loaded, a database query is run to determine what username belongs to the logged in user requesting the page which ensures that the proper name is displayed. If you were to cache this page, then the the database query would not happen and all users would see the same username at the top of the page and it likely will not be their username. You need that query to happen on every page load to ensure that the proper username is displayed to each user. It is therefore not cacheable.
Extend that logic to something a little more problematic like user permissions and you can see why dynamic content should not be cached. If the database is not hit for dynamic content, the CMS has no way to determine whether the user requesting the page has permissions to see that page.
Static content is, by definition, the same for all users. Therefore no database query needs to take place to customize that page for each user so it makes sense to cache that to eliminate needless database queries. Images are a really great example of static content - you want all users to see the same header image, the same login buttons, etc, so they are excellent candidates for caching.
In your code snippet above you're seeing a very typical Varnish VCL snippet which forces images, css and javascript to be cached. By default, Varnish will not cache any request with a cookie in it. The logic being that if there is a cookie in the request, then there must be some reason the server needs that cookie so it is required on the back end and must be passed through the cache. In reality, many CMSes (Drupal, Wordpress, etc) attach cookies to almost everything whether or not it is needed so it is common to write VCL to strip the cookies out of content that is known to be static which in turn causes Varnish to cache it.
Make sense?
Для динамического содержимого , некоторые вроде котировок акций на самом деле часто меняются (обновляются каждую секунду на сервере SaaS с внутреннего сервера ), но могут запрашиваться еще чаще (десятками тысяч клиентов подписки ):
[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]
В этом случае кэширование на SaaS-сервере посекундное обновление с внутренних серверов позволяет удовлетворить запросы десятков тысяч пользователей подписки .
Без кеша на сервере SaaS эта модель была бы просто не работает.
Кэширование статических файлов с помощью Varnish было бы лучше с точки зрения разгрузки Nginx. Конечно, если у вас есть много статических файлов для кеширования, это приведет к потере оперативной памяти. Однако у Varnish есть приятная особенность - он поддерживает несколько бэкэндов для своего кеша.
Для статических файлов: кэшировать на жесткий диск. Для всего остального: кэшировать в ОЗУ.
Это должно дать вам больше информации о том, как реализовать этот сценарий: http://www.getpagespeed.com/server-setup/varnish-static-files-cache