Организация Apache Software Foundation представила (https://blogs.apache.org/foundation/entry/media_alert_the_ap...) релиз высокопроизводительного http-сервера Apache Traffic Server 3.2 (http://trafficserver.apache.org/), который может выступать в роли промежуточного звена, перенаправляющего запросы к фронтэндам, генерирующим динамический контент, или обеспечить отдачу статических объектов, таких как файлы, JavaScript, CSS и картинки. Сервер также включает в себя набор сервисов для работы в качестве распределенной облачной-системы, такие как средства конфигурирования, управления сессиями, балансировки, авторизации и маршрутизации запросов.
Изначально продукт был создан в недрах компании Yahoo, но в 2009 году переведен в разряд открытых проектов и отдан под опеку фонда Apache. Traffic Server позволяет организовать работу системы динамической обработки HTTP-запросов, которая использовалась в Yahoo последние 10 лет и до сих пор задействована для ежедневной доставки конечным пользователям около 400 терабайт контента. Ежедневно Traffic Server обслуживает отдачу пользователям Yahoo примерно 30 миллиардов объектов. При тестировании производительности Traffic Server смог обеспечить отдачу более 200 тысяч небольших объектов в секунду при задействовании кэширования в ОЗУ или 100 тыс. объектов в секунду без использования кэширования.Основные особенности Apache Traffic Server:
- Кэширование: уменьшение времени ответа, снижение нагрузки на сервер и сокращение внутреннего трафика за счет повторного использования и кэширования отдачи часто запрашиваемых web-страниц, изображений и обращений к web-сервисам;
- Работа в качестве прокси: поддержка keep-alive, фильтрации и анонимизации запросов контента, использование в качестве балансировщика нагрузки;
- Скорость: высокая степень масштабируемости на современных многоядерных системах, способность обрабатывать на обычном оборудовании десятков тысяч запросов в секунду;
- Расширяемость: доступен API для разработки расширяющих функциональность плагинов, способных решать различные задачи, такие как изменение HTTP-заголовков и содержимого отдаваемого контента или создание обработчиков c реализацией поддержки новых протоколов;- Надежность: система проверена в промышленной эксплуатации и используется для отдачи сотен терабайт трафика.
Новшества, добавленные в Apache Traffic Server 3.2:
- Полная поддержка IPv6, в том числе во всех API для плагинов (в прошлой версии IPv6 поддерживался только на стороне клиента);
- Поддержка SSL/TLS-расширений SNI (Server Name Indication) и NPN (Next Protocol Negotiation). Проведена работа по увеличению стабильности функционирования SSL;
- Новые гибкие возможности настройки для управления IP-адресами и сетевыми портами, обслуживающими входящие запросы и исходящие ответы. Отныне можно привязывать Apache Traffic Server к любым комбинациям адресов и портов для HTTP и HTTPS;- Существенно увеличена скорость отдачи отдельных кусков больших объектов из кэша с использованием заголовка Range;
- Расширение API для разработки плагинов;
- Увеличение масштабируемости и производительности кластерного кэша (Cluster Cache);
- Значительное улучшение производительности при проксировании бэкенда, поддерживающего Keep-Alive соединения. Существенно увеличена общая производительность кэша;
- Расширение числа входящих (https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;...) в базовую поставку плагинов (conf_remap, header_filter, regex_remap, stats_over_http, balancer, buffer_upload, cacheurl, geoip_acl, gzip, header_rewrite, lua, memcached_remap, mysql_remap);
- Поддержка всех версий GCC начиная с 4.1.2, а также Clang/LLVM 3 и компилятора Intel C/C++ Compiler (ICC).URL: https://blogs.apache.org/foundation/entry/media_alert_the_ap...
Новость: http://www.opennet.ru/opennews/art.shtml?num=34157
Убийца Nginx?
Костыль для апача. Он с 2009 года нжинкс так "убивает" что у того рыночная доля растет как на дрожжах. И вообще, апачевый инкубатор - дефолтное место слива отработанного материала у проприетарщиков. Вот и яха 3 года назад отметились.
Школота детекдет, что тут скажешь. Новость хотя-бы прочитай.
Это, вообще-то, не конкурент nginx, а дополняющий сервис. Позволяет эффективно кешировать уменьшать латентность nginx-based сервисов, и реализовывать фичи вроде поддержки ssl-вебсокетов на 443 порту (в nginx пока это нормально не сделать).Это, скорее, убийца haproxy: может все то же самое и даже больше и при этом меньше латентность и лучше показатели по максимальному числу запросов в секунду.
>> nginx-basedЭто как?
основанные на nginx, другими словами, сервисы которые используют nginx
>Позволяет эффективно кешировать
> уменьшать латентность nginx-based сервисовДа, я щитаю, хорошо, что апачи наконец поучат этого зазнавшегося енджина _статику _раздавать! Пора, пора осадит нахала!!</,>
load balanser у него плагином.
На FreeBSD замечено пожирание памяти, леится регулярными перезагрузками.
Относительно nginx более вкусен своими логами и правилами перенаправления.
Одна строчка одно правило, и сразу можно посмотреть трафик по этому правилу в реальном времени. А в остальном тоже самое тока в профиль.
> На FreeBSD замечено пожирание памяти, леится регулярными перезагрузками.Давайте еще ребутать серваки регулярно, как виндовые компы...
а что делать - любишь поделки в продакшене люби и ребутаться
поэтому только линукс и нжинкс :)
> поэтому только линукс и нжинкс :)FreeBSD + nginx
//fixed
возможно, я что-то не понял, но, кажется, речь идет о перезагрузке сервиса, что, конечно, тоже ненормально. Забавно другое - слово "перезагрузка" у вас однозначно асоциируется с ребутом. К чему бы это?
>слово "перезагрузка"
>асоциируется с ребутом. К чему бы это?Скверное применение хорошего:) знания английского?:))))
Наречие "ещё" как бе намекает, что Анонимус иронизирует :)
В противном случае - это Windows головного мозга.
linux-only style?
Похоже, в рассылке сосласись на то что "такое может быть с некоторыми старыми libc"
А какая фряха была?
8.2, 9.0. ATS 3.0.4
Вчера вышел в портах ATS 3.0.5, посмотрим как он себя поведет
А что лучше в качестве фронтенда для нескольких дюжин проектов с небольшой нагрузкой ATS или Squid?
По фичам они оба неплохи, по латентности ATS сильно меньше (лучше). Под *совсем* маленькую нагрузку squid может быть удобнее, если, скажем, с его конфигами админ знаком, а с ATS нужно разбираться; но если планируется рост, лучше ATS.Тут хороший бенчмарк - ATS по сравнению с varnish и squid не только всегда быстрее и всегда имеет меньшую латентность, но так же наименьшее количество ошибок под нагрузкой по сравнению с ними.
http://daemonkeeper.net/735/apache-trafficserver-the-better-.../
varnish
ATS Очень прост в настройке и мониторинге, так что ATS
> ATS Очень прост в настройке и мониторинге, так что ATSпрост в мониторинге - это как?
Как я понимаю из прочтения док - функциональный аналог Сквида, есть как прямой, так и обратный кеширующий прокси.