Как проверить, работает ли Squid в качестве обратного прокси?

Question

Мы хотим уменьшить нагрузку на одном из наших веб-серверов, и мы запускаем некоторые тесты с squid, настроенными как обратный прокси.

Конфигурация в приведенных ниже замечаний:

http_port 80 defaultsite = Accel original.server.com

cache_peer original.server.com родитель 80 0 нет-запрос имени originserver = myAccel

our_sites dstdomain ACL .contentpilot.net

http_access позволяют our_sites

cache_peer_access myAccel позволяют our_sites

cache_peer_access myAccel все отрицают

Ситуация, которую мы имеем, что в значительной степени сервер возвращает TCP_MISS почти все время.

1238022316.988  86 69.15.30.186 TCP_MISS/200 797 GET http://original.server.com/templates/site/images/topnav_givingback.gif - FIRST_UP_PARENT/myAccel - 
1238022317.016  76 69.15.30.186 TCP_MISS/200 706 GET http://original.server.com/templates/site/images/topnav_diversity.gif - FIRST_UP_PARENT/myAccel - 
1238022317.158  75 69.15.30.186 TCP_MISS/200 570 GET http://original.server.com/templates/site/images/topnav_careers.gif - FIRST_UP_PARENT/myAccel - 
1238022317.344  75 69.15.30.186 TCP_MISS/200 2981 GET http://original.server.com/templates/site/js/home-search-personalization.js - FIRST_UP_PARENT/myAccel - 
1238022317.414  85 69.15.30.186 TCP_MISS/200 400 GET http://original.server.com/templates/site/images/submenu_arrow.gif - FIRST_UP_PARENT/myAccel - 
1238022317.807  75 69.15.30.186 TCP_MISS/200 2680 GET http://original.server.com/templates/site/js/homeMakeURL.js - FIRST_UP_PARENT/myAccel - 
1238022318.666 1401 69.15.30.186 TCP_MISS/200 103167 GET http://original.server.com/portalresource/lookup/wosid/intelliun-2201-301/image2.jpg - FIRST_UP_PARENT/myAccel image/pjpeg 
1238022319.057 1938 69.15.30.186 TCP_MISS/200 108021 GET http://original.server.com/portalresource/lookup/wosid/intelliun-2201-301/image1.jpg - FIRST_UP_PARENT/myAccel image/pjpeg 
1238022319.367  83 69.15.30.186 TCP_MISS/200 870 GET http://original.server.com/templates/site/images/home_dots.gif - FIRST_UP_PARENT/myAccel - 
1238022319.367  80 69.15.30.186 TCP_MISS/200 5052 GET http://original.server.com/templates/site/images/home_search.jpg - FIRST_UP_PARENT/myAccel - 
1238022319.368  88 69.15.30.186 TCP_MISS/200 5144 GET http://original.server.com/templates/site/images/home_continue.jpg - FIRST_UP_PARENT/myAccel - 
1238022319.368  76 69.15.30.186 TCP_MISS/200 412 GET http://original.server.com/templates/site/js/showFooterBar.js - FIRST_UP_PARENT/myAccel - 
1238022319.377 100 69.15.30.186 TCP_MISS/200 399 GET http://original.server.com/templates/site/images/home_arrow.gif - FIRST_UP_PARENT/myAccel - 

Мы уже попытались удалить всю кэш-память. Есть идеи. Может быть, мой веб-сайт каждый раз помечает часть контента, даже если он не изменился с тех пор, как последний запрос был запрошен прокси?

Answer 1

Какие заголовки отправляются сервером происхождения (веб-сервером) с вашего содержимого? Для того, чтобы быть кэшируемым с помощью squid, я считаю, что вам обычно нужно указать либо Last-Modified, либо ETag в заголовке ответа. Веб-серверы обычно делают это автоматически для статического контента, но если ваш контент динамически обслуживается (даже если из статического источника), то вы должны убедиться, что они есть, и обрабатывать заголовки запросов, такие как If-Modified-Since и If- None-Match.

Кроме того, поскольку я указал на этот вопрос вашим последующим вопросом о сеансах --- есть ли в ответе заголовок «Vary»? Например, «Vary: Cookie» сообщает кэшам, что содержимое может варьироваться в зависимости от заголовка Cookie в запросе: поэтому статический контент хочет удалить его. Но ваш веб-сервер может добавлять это ко всем запросам, если есть сеанс, независимо от статического/динамического характера обслуживаемых данных.

По моему опыту, некоторые эксперименты с заголовками HTTP, чтобы увидеть, какие эффекты оказывают на кеширование, имеют большую пользу: я помню, что решение было не всегда очевидным.

Answer 2

Изучите заголовки, возвращенные с помощью wirehark или firebug в firefox (последний легче проталкивать, но первый даст вам более низкоуровневую информацию, если вам это понадобится).

Посмотрите на эти предметы в заголовки ответа (нажмите на элемент в представлении `Net», чтобы развернуть его и увидеть заголовки запроса и ответа):

• дату последнего изменения -> если не установлен разумное время в прошлом, тогда оно не будет кэшировано
• Etags -> если они меняются каждый раз, когда тот же самый объект запрашивается, он будет повторно выбран
• Cache-Control -> Запросы от клиента с max -age = 0 будет (я считаю) каждый раз запрашивать новую копию страницы
• (изменить) Истекает заголовок -> Если это установлено в прошлом (т. всегда истек), тогда squid не будет кэшировать его

Как было предложено araqnid, заголовки HTTP могут иметь огромное значение для того, что прокси-сервер будет считать кеш-память. Если ваш back-end использует apache, тогда проверьте, что статические файлы, обслуживаемые без перехода через любой PHP или другой прикладной уровень, можно кэшировать.

Кроме того, убедитесь, что настройки squid для maximum_object_size и minimum_object_size установлены на разумные значения (по умолчанию это 4Mb и 0kb, что должно быть хорошо), а также возрастает максимальный возраст элемента кэша. (см. http://www.visolve.com/squid/squid30/cachesize.php#maximum_object_size для этой и других настроек)