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

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

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

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

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

Приветствия

Ян

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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

Ответ 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 и целый ряд других больших имен, также использующих его.

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

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

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

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

Ответ 11

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