Как проверить, что Squid используется как обратный прокси? - PullRequest
Новая
       16

Как проверить, что Squid используется как обратный прокси?

4 голосов
/ 26 марта 2009

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

Конфигурация указана ниже:

http_port 80 accel defaultsite = original.server.com

cache_peer original.server.com parent 80 0 имя сервера без запроса name = myAccel

acl our_sites dstdomain .contentpilot.net

http_access allow our_sites

cache_peer_access myAccel разрешить наши_сайты

cache_peer_access myAccel deny all

Ситуация, с которой мы сталкиваемся, заключается в том, что сервер почти все время возвращает 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 -

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

Ответы [ 2 ]

3 голосов
/ 17 апреля 2009

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

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

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

1 голос
/ 21 апреля 2009

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

Найдите эти элементы в заголовках ответа (щелкните элемент в представлении «Сеть», чтобы развернуть его и увидеть заголовки запроса и ответа):

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

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

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

...