Организация Apache Software Foundation объявила (https://blogs.apache.org/trafficserver/entry/v4_0_1_is_finally) о выходе высокопроизводительного http-сервера Apache Traffic Server 4.0 (http://trafficserver.apache.org/), который может выступать в роли промежуточного звена, перенаправляющего запросы к бэкэндам, генерирующим динамический контент, или обеспечить отдачу статических объектов, таких как файлы, JavaScript, CSS и картинки. Traffic Server также включает в себя набор сервисов для работы в качестве распределенной системы, в том числе средства конфигурирования, управления сессиями, балансировки, авторизации и маршрутизации запросов.
Apache Traffic Server поддерживает режим кэширования, позволяющий
снизить нагрузку на сервер и сократить внутренний трафик за счет повторного использования и кэширования отдачи часто запрашиваемых web-страниц, изображений и обращений к web-сервисам. Для запросов которые не поддаются кэшированию может применяться режим прокси, предоставляющий средства балансировщика нагрузки и фильтрации запросов. Для расширения функциональности Apache Traffic Server предоставляется API для разработки плагинов, способных решать различные задачи, такие как изменение HTTP-заголовков и содержимого отдаваемого контента или создание обработчиков c реализацией поддержки новых протоколов.Изначально продукт был разработан компанией Yahoo, но в 2009 году переведен в разряд открытых проектов и передан фонду Apache. Traffic Server используется в Yahoo для обеспечения работы системы динамической обработки HTTP-запросов, ежедневно доставляющая конечным пользователям около 400 терабайт контента и 30 миллиардов объектов. При тестировании производительности Traffic Server смог обеспечить отдачу более 200 тысяч небольших объектов в секунду при задействовании кэширования в ОЗУ или 100 тыс. объектов в секунду без использования кэширования.
Основные изменения (https://cwiki.apache.org/confluence/display/TS/What%27s...):
- Возможность привязки URL к определённым хранилищам. Например, можно организовать кэширование определённого контента только на SSD-накопителях;
- Средства для управления HTTP-транзакциями с учётом текущего потребления памяти при их обработке. Новая версия позволяет ограничить пропускную способность в случае если размер размещаемого в памяти буфера превышает определённую границу и снять ограничение при восстановлении ситуации с расходом памяти. С использованием плагинов ограничения также могут задаваться для отдельных транзакций;
- Поддержка привязки основных обработчиков к фиксированным ядрам CPU, исключая миграцию между CPU;
- Поддержка обработки запросов HTTP Range;
- Новые плагины: gzip и cacheurl;
- Режим приостановки проксирования до окончания инициализации кэша (временная недоступность кэша первые моменты после запуска сервера может привести к нежелательному всплеску запросов к бэкенду);
- Возможность кэширования контента нулевой длины (полезно для кэширования редиректов);
- Поддержка дублирования элементов кэша на разных узлах кластера;
- Расширено число опций для которых допускается переопределение через API плагинов или через модуль conf_remap.so;
- В API плагинов добавлены хуки для получения управления во время инициализации сетевого порта, готовности к приёму соединений и готовности кэша;
- Изменение формата хранилища кэша. При переходе на версию 4.0 требуется переинициализация (https://cwiki.apache.org/confluence/display/TS/Upgrading+to+...) кэша.
Дополнительно отмечается изменение процесса подготовки релизов. Значительные релизы будут выходить один раз в год, а промежуточные - раз в квартал. В рамках значительного релиза будет гарантироваться обратная совместимость на уровне API, ABI, функциональности и формата кэша. Master-ветка в Git теперь будет постоянно поддерживаться в стабильном виде, готовом к релизу в любой момент, что позволит использовать срез данной ветки в качестве замены тестовых выпусков.
URL: https://blogs.apache.org/trafficserver/entry/v4_0_1_is_finally
Новость: http://www.opennet.ru/opennews/art.shtml?num=37851
И чем оно лучше nginx?
Не знаю, лучше или хуже - они просто разные.
1. Контроля буферизации, допустим, в nginx как не было, так и нет
2. Уровень разработки и подходов немножко иной, честно говоря
3. nginx - это более-менее универсальный web-сервер, trafficserver - практически чистая прокся, оптимизированная под свою задачу
4. В nginx в режиме прокси заголовки (как запроса, так и ответа) буферизуются полностью, да и с буферизацией контента всё не так гладко - полная буферизация в RAM или на диск. trafficserver может передавать заголовки и контент синхронно с буферизацией
5. С другой стороны - traffic server'ом статику не поотдаёшь :) - только с дочернего Web-сервера
> да и с буферизацией контента всё не так гладко - полная буферизация в RAM или на дискВас глючит, вы наверное с лайти перепутали. Нжинксу не обязательно целиком кешировать то что он проксирует, он по мере готовности гоняет данные между сокетами.
Это всеобщее заблуждение, наверное из за того что nginx благотворят :-)Nginx буферезирует запрос клиента перед передачей этого запроса бекенду. Многие этого не замечают так как этот эффект проявляется только при загрузке больших файлов на сервер (POST/PUT) :-)
Ну и если ещо закрыть глаза на немного запутанный синтаксис конфиг файла , то вполне удачный сервер.
> Ну и если ещо закрыть глаза на немного запутанный синтаксис конфиг файла
> , то вполне удачный сервер.В смысле, Вам всерьез синтаксис апачевских конфигов кажется проще? О_о
Всё жи искаропки, только добавить пару строчек с путями, ага.
Сильно зависит от вендора ОС и дистра. Сильно сомневаюсь, что вы отделаетесь даже 10ю строками конфига :)
> Контроля буферизации, допустим, в nginx как не было, так и нетЧем это эффективнее файловой буферизации?
Тем, что не упрётся в диск в самый непредсказуемый момент.
а что, кто-то на реально нагруженных фронтэндах держит все это на диске, а не в tmpfs?
> а что, кто-то на реально нагруженных фронтэндах держит все это на диске,
> а не в tmpfs?А не костыль?
костыль. рабочий, но костыль.
Это может быть в том случае, когда размер буфера у файловой системы минимален, а различные запросы к файловой системе со стороны сервера не приводят к его заметному увеличению. Вот тогда да — рандомные реквесты убивают производительность сервера и нужна промежуточная буферизация средствами самого сервера.
Оно держит побольше нжинкса. эксплуатировалось на ~30млн запросах в день, нжинкс дохнет гораздо быстрее. Но апач тоже нет нет да сдохнет. Самой надежной оказалась HAproxy.
Еще относительно нжинкса поудобнее в апаче правила редиректов писать, особенно когда их много.
> эксплуатировалось на ~30млн запросах в день, нжинкс дохнет гораздо быстрееОценку в миллионах запросах в день, оставьте менеджерам, они любят большие циферки.
Для оценки производительности полезнее указывать кол-во запросов в секунду при пиковой нагрузке (и запросы в секунду из запросов в день не выводятся - соотношение средней и пиковой нагрузки у всех немного разное).
Так вот 30млн запросах в день это всего 347 запроса в секунду в среднем - очень маленькая нагрузка для любого веб сервера. На проксировании небольших запросов nginx волне можно обрабатывать 10 тыс в секунду и больше, если железо не очень слабое.
Ну и поскольку чудес не бывает, то Apache Traffic Server (если его авторы не допустили явных косяков) и nginx должны держать примерно одинаковую нагрузку.
Весьма интересно в этом смысле следующее заявление:"Traffic Server is fast. It was designed from the start as a multi-threaded event driven server, and thus scales very well on modern multi-core servers. With a quad core 1.86GHz processor, it can do more than 30,000 requests/second for certain traffic patterns. In contrast, some of the other caching proxy servers we've used max out at around 8,000 requests/second using the same hardware."
Полный текст можно найти здесь http://ostatic.com/blog/guest-post-yahoos-cloud-team-open-so...
Если верить этому заявлению, то nginx существенно медленнее сабжа.
Нет. Просто глупый антон сказал глупость про нджинкс. Нджинкс умеет до 100k запросов в секунду.
> Нет. Просто глупый антон сказал глупость про нджинкс. Нджинкс умеет до 100k запросов в секунду.Кто больше ?
5.13, Аноним, 18:29, 08/09/2013 - продано!
10тыс хелло вордов да. А реального трафа фигушки.
Сынок :) А что такое "реальный траф"?
У меня nginx-ы не на последнем овне сидят, и я их после деплоя в DC так и не смог положить в полочку по процу. Вначале дискоыфй ио вышел в полочку (и пришлось сильно поковырять лоад скрипт чтобы оно не могло закжшить разок а потом с тамяти раздовать)."хеловордов" как тут щенки слюнявые писали nginx может разадать столько ... сколько ваш NIC унесёт :)
> "хеловордов" как тут щенки слюнявые писали nginx может разадать столько ... сколько
> ваш NIC унесёт :)собственно когда упирается в NIC, тогда можно сказать, что всё отлично настроено ;)
Правильно говориш, nginx оптимизирован лучше. Сысоев молодца.
Ну насчет 30 млн. в день не скажу, а 22-25к параллельных запросов nginx у меня обслуживал как родной. HAproxy кстати я так и не успел там до ума довести - дохла с возвратом 500-й (руки у меня видать еще не самой оптимальной формы были), потому вот собрал быстренько балансир на nginx и был доволен результатом. Жаль сабж там не успел посчупать - сроки.
Зашел, чтобы увидеть этот вопрос.
Если мне не изменяет память, в отличие от nginx он "keep-alive" держать может.
nginx умеет keep-alive
А до бэкендов?
И до бэкендов:http://nginx.org/en/docs/http/ngx_http_upstream_module.html#...
This directive appeared in version 1.1.4, то есть ещё в сентябре 2011.
>Новые плагины: gzip"Актуальненько" выглядит в свете недавнего шума с BEAST атакой.
>>Новые плагины: gzip
> "Актуальненько" выглядит в свете недавнего шума с BEAST атакой.А что вам BEAST? Отключайте сжатие на ssl-локейшенах.
>>>Новые плагины: gzip
>> "Актуальненько" выглядит в свете недавнего шума с BEAST атакой.
> А что вам BEAST? Отключайте сжатие на ssl-локейшенах.А зачем не-ssl локейшены?
>>>>Новые плагины: gzip
>>> "Актуальненько" выглядит в свете недавнего шума с BEAST атакой.
>> А что вам BEAST? Отключайте сжатие на ssl-локейшенах.
> А зачем не-ssl локейшены?Что за вопрос. Вам что весь контент в ssl? Зачем? Хватит логин формы + платежка, например.
>>> Отключайте сжатие на ssl-локейшенах.
>> А зачем не-ssl локейшены?
> Что за вопрос. Вам что весь контент в ssl? Зачем? Хватит логин формы + платежка, например.В Париже так уже не носят, если чо.
> Apache Traffic Server поддерживает режим кэширования, позволяющий снизить нагрузку на сервер и сократить внутренний трафик за счет повторного использования и кэширования отдачи часто запрашиваемых web-страниц, изображений и обращений к web-сервисам. Для запросов которые не поддаются кэшированию может применяться режим прокси, предоставляющий средства балансировщика нагрузки и фильтрации запросов.Забавно, как аналоги proxy_pass и proxy_cache представляются, как нечто, чего мир ещё не видел)
Судя по описанию, ещё один веб сервер, менее фичный, чем nginx.
Сысоев избаловал нас отличным веб сервером, да :)Кстати, вот двухгодичное сравнение веб серверов.
Тестируется отдача маленькой статики напрямую - тест довольно синтетический.
http://nbonvin.wordpress.com/2011/03/24/serving-small-static.../nginx и Apache Traffic Server показывают одинаковую скорость, только nginx ест меньше ресурсов.
А по скорости всех заруливает G-WAN, но это вообще специфичная штука.
G-WAN идет с заплатками АНБ
>> G-WAN идет с заплатками АНБой !
> G-WAN идет с заплатками АНБДа, сейчас про это модно вспоминать)
Вообще продукт мутный, сырцов нет, сам платный.
И ещё разработчик один и с позицией "В моем ПО багов нет, а если и есть, платите деньги и я их исправлю, может быть".
Лучше Varnish ?
Белизна-М, и пятен как не бывало!
> Лучше Varnish ?varnish что-то вообще проигрывает nginx'у в 2 раза, см. ссылочку из моего поста выше.
Во всяком случае, проигрывал в 2011 году.