Такс, Лак или Кальмар?

Question

Нам нужен ускоритель веб-контента для статических изображений перед нашими веб-серверами Apache

Наш предыдущий партнер по хостингу использовал Tux с большим успехом, и мне нравится тот факт, что он является частью Red Hat Linux, которую мы используем, но его последнее обновление было в 2006 году и, похоже, шансы на дальнейшее развитие невелики. Наш провайдер рекомендует использовать Squid в роли обратного кэширования прокси.

Есть какие-нибудь мысли между Tux и Squid? Совместимость, надежность и поддержка в будущем так же важны для нас, как и производительность.

Кроме того, я читал в других темах о Varnish; У кого-нибудь есть реальный опыт использования Varnish по сравнению со Squid и / или Tux, полученный в условиях интенсивного трафика?

Приветствия

Ian

ОБНОВЛЕНИЕ: сейчас мы тестируем Squid. Используя ab, чтобы получить одно и то же изображение 10000 раз с параллелизмом 100, Apache сам по себе и Squid / Apache быстро обрабатывали запросы. Но Squid сделал только один запрос к Apache на изображение, а затем отправил их все из ОЗУ, тогда как одному Apache пришлось отбросить большое количество рабочих для обслуживания изображений. Похоже, что Squid будет хорошо освобождать работников Apache для обработки динамических страниц.

Answer 1

По моему опыту, лак намного быстрее, чем squid, но не менее важно, что он намного меньше черного ящика, чем squid. Varnish дает вам доступ к очень подробным журналам, которые полезны при устранении неполадок. Его язык конфигурации также намного проще и мощнее, чем язык Squid.

Answer 2

@ Даниэль, @MKUltra, если говорить о предполагаемых проблемах Варниша с печеньем, то их на самом деле нет. Совершенно нормально , а не кэшировать запрос, если он возвращает cookie с ним. Куки-файлы в основном предназначены для различения пользовательских предпочтений, поэтому я не думаю, что кто-то захочет их кэшировать (особенно если вы включаете некоторую секретную информацию, такую ​​как идентификатор сессии или пароль!).

Если ваш сервер отправляет куки с вашими .js и изображениями, это проблема на вашей стороне сервера, а не на стороне Varnish. Как указывает @Daniel (ссылка предоставлена), вы в любом случае можете принудительно кэшировать эти файлы благодаря действительно классному языку / DSL, встроенному в Varnish ...

Answer 3

Если вы хотите использовать статические изображения и многие из них, вы можете сначала взглянуть на некоторые основы.

Ваше приложение должно обеспечить передачу всех правильных заголовков, например, Cache-Control и Expires. Это должно привести к тому, что клиентские браузеры будут кэшировать эти изображения локально и сократить количество запросов.

Используйте CDN (если это в вашем бюджете), это приблизит изображения к вашим клиентам (как правило) и приведет к улучшению работы пользователей. Чтобы CDN был продуктивным вложением, вам снова нужно убедиться, что все необходимые заголовки кэширования установлены правильно, согласно пункту, который я сделал в предыдущем абзаце.

В конце концов, если вы все еще собираетесь использовать обратный прокси, я рекомендую использовать nginx в режиме прокси, поверх Varnish и Squid. Да, Varnish работает быстро и так же быстро, как nginx, но то, что вы хотите сделать, на самом деле довольно просто, Varnish вступает в свои права, когда вы хотите выполнять сложное кэширование и ESI. Так что будь проще, глупый. nginx очень хорошо выполнит вашу работу.

У меня нет опыта работы с Tux, поэтому я не могу комментировать это извините.

Answer 4

Несмотря на это, я недавно настроил nginx в качестве обратного прокси-сервера перед Apache на 6-летнем маломощном веб-сервере (работающем с Fedora Core 2), который подвергался легкой атаке DDoS (10K req / сек). Загрузка страниц была быстрой (<100 мс), а нагрузка на систему оставалась низкой - около 20% загрузки ЦП и очень небольшое потребление памяти. Атака длилась 1 неделю, и посетители не увидели вредных последствий. </p>

Неплохо для более чем полумиллиона ударов в минуту. Просто не забудьте войти в /dev/null.

Answer 5

Мы используем Varnish для http://www.mangahigh.com и смогли масштабировать от примерно 100 одновременных предварительных лаков до более чем 560 одновременных пост-лаков (нагрузка на сервер на этом этапе оставалась равной 0, поэтому есть много места для роста !). Документация по лаку может быть лучше, но она достаточно гибкая, когда вы к ней привыкнете.

Лак должен быть намного быстрее, чем Squid (никогда не использовал Squid, я не могу сказать наверняка), а http://users.linpro.no/ingvar/varnish/stats-2009-05-19 показывает Twitter, Wikia, Hulu, perezhilton.com и довольно много другие громкие имена также используют его.

Answer 6

Интересно, что никто не упомянул Apache Traffic Server (ранее Yahoo! Traffic Server) http://trafficserver.apache.org/

Пожалуйста, посмотрите на это, оно прекрасно работает.

Answer 7

Я использовал только кальмаров и не могу сравнить. Мы используем squid для кэширования всего сайта на сервере в США (все данные извлекаются с машины в Германии). Это было довольно легко настроить и хорошо работает. Я обнаружил, что документации не хватает, если вы уже не знаете, что искать.

Answer 8

Squid и nginx специально разработаны для этого. nginx особенно прост в настройке для фермы серверов и также может быть интерфейсом для FastCGI.

Answer 9

Поскольку у вас уже есть Apache, обслуживающий статический и динамический контент, я бы порекомендовал вам использовать Varnish.

Таким образом, вы можете использовать свой apache для доставки статического контента и использовать лак для его кеширования. Varnish очень гибок, предоставляя вам как функции кэширования, так и балансировки нагрузки для оптимального роста вашего сайта.

Answer 10

Никто не упоминает, что Squid следует спецификации HTTP письму (или, по крайней мере, они пытаются), тогда как Varnish - нет. На мой взгляд, это означает, что Varnish лучше подходит для кэширования контента для отдельных сайтов (путем обширной настройки Varnish), а Squid лучше подходит для кэширования контента для многих сайтов (каждый из которых должен будет сделать свой контент «кэшируемым» в соответствии с спецификации ).