Тукс, лак или кальмар?

Question

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

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

Любые мысли между Тукс и Кальмаром? Совместимость, надежность и будущая поддержка важны для нас как производительность.

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

Приветствия

Ian

UPDATE: Мы тестируем Squid в настоящее время. Используя ab, чтобы вытащить одно и то же изображение 10 000 раз с параллелизмом в 100, оба Apache сами по себе, а Squid/Apache сжигались по запросам очень быстро. Но Squid сделал только один запрос к Apache для изображения, а затем обслужил их всех из ОЗУ, тогда как Apache сам должен был раскошеливать большое количество работников, чтобы служить изображениям. Похоже, Squid будет хорошо работать, освобождая рабочих Apache для обработки динамических страниц.

Answer 1

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

Answer 2

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

Answer 3

Мы собираемся выставить лак 2.01 на сервере перед установкой IIS 6. Единственные предостережения, которые у нас были, были с нашим SSL (поскольку лак не может обрабатывать SSL). Поэтому мы также установили Nginx для обработки этих запросов.

Во всех наших тестах мы показали увеличение на 66% процента объема трафика, который может обрабатывать сайт.

Моя единственная проблема заключается в том, что лак плохо обрабатывает куки, а документация все еще немного разбросана.

Answer 4

В моем опыте лак намного быстрее, чем кальмар, но не менее важно, что он намного меньше черного ящика, чем кальмары. Лак дает вам доступ к очень подробным журналам, которые полезны при отладке проблем. Это язык конфигурации также намного проще и гораздо более мощным, чем у кальмаров.

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

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

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

Answer 7

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

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

Answer 8

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

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

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

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

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

Answer 9

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

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

Answer 10

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

Answer 11

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

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