На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2001-6-22 на главную / новости от 2001-6-22
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 22 июня 2001 г.

Red Hat Tux 2.0 затмевает Apache

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

Именно такой итог увенчал испытания веб-серверов в лаборатории eWeek Labs, в которых веб-сервер Tux 2.0 от Red Hat на базе ядра Linux 2.4 намного превзошел все мыслимые до сих пор пределы производительности и указал путь будущим веб-серверам на базе той же архитектуры.

Тесно сотрудничая с группой Performance Engineering компании Dell Computer (она первой опубликовала впечатляющие результаты Tux в тестах SPECWeb 99), eWeek Labs обнаружила, что при обработке комбинированного динамического и статического веб-контента Tux работает почти втрое быстрее, чем популярный веб-сервер Apache (12792 против 4602 транзакций в секунду).

60,7 Мбайт статического веб-контента легко умещается в оперативной памяти, так что этот тест проверяет главным образом сетевые механизмы и управление потоками, но не управление дисковой памятью (хотя logging веб-сервера во время испытаний был включен).

Бешеная производительность
Замечательное быстродействие Tux даже на слабом оборудовании служит доказательством эффективности его необычного дизайна: во-первых, для ускорения работы Tux помещает код веб-сервера в ядро и считывает веб-страницы непосредственно из кэша файловой системы kernel-mode Linux; во-вторых, Tux очень эффективно управляет большим числом соединений, используя ограниченный пул рабочих потоков, а не одного рабочего процесса на каждое соединение, как Apache; в-третьих, Tux использует свой собственный высокопроизводительный алгоритм планирования потоков, минимизирующий влияние дисковых операций.

Tux очень легко внедрять на предприятии поэтапно, так как он способен прозрачно переадресовывать веб-запросы, которые не может обработать, на другой веб-сервер, например, на тот же Apache. Главный недостаток Tux заключается в том, что он не поддерживает трафик Secure Sockets Layer — реализация этой возможности запланирована на следующую версию.

Тот факт, что Tux 2.0 оказался значительно быстрее, чем веб-сервер Internet Information Server 5.0 из Windows 2000 (5137 запросов в секунду), наглядно демонстрирует преимущества новой конструкции Tux по сравнению с этим популярным веб-сервером. Следующая версия IIS (которая входит в проект Microsoft Whistler) использует несколько идей, реализованных в Tux, в том числе kernel-space организацию. Kernel-space веб-кэш (но не kernel-space веб-сервер) применяется в IBM AIX с 1999 года, так что тенденция внедрения в ядро становится популярной.

С системной точки зрения бешеная производительность Tux и подобных ему веб-серверов обеспечит организациям возможность создавать у себя более быстродействующие и масштабируемые фермы веб-серверов с меньшим количеством серверов и процессоров, что позволит высвободить ресурсы для приобретения более мощных и качественных серверов приложений и баз данных.

Ядро вашей мечты
В этом тесте мы хотели получить также количественные оценки многочисленных изменений, внесенных в ядро Linux 2.4 с целью повышения масштабируемости и производительности. Результаты со всей очевидностью доказали, что Linux 2.4 – как с Tux, так и с Apache — работает намного быстрее, чем Linux 2.2.

Как уже упоминалось, внутренняя архитектура Tux оптимизирована в расчете на высокую производительность, но, по словам главного автора Tux Инго Молнара (Ingo Molnar), системного инженера Red Hat в Берлине, это лишь один из пяти факторов, вносящих вклад в столь превосходное быстродействие. Остальные четыре фактора связаны с особенностями ядра Linux 2.4 и способствуют ускорению любого приложения Linux-сервера: zero-copy TCP/IP networking, interrupt and process CPU affinity, выделение ресурсов памяти ядра каждому CPU (slab caches) и wake-one scheduling. (Некоторые функции, включая zero-copy networking, требуют внесения изменений в серверные приложения.)

Молнар отмечает также большие успехи в оптимизации ядра 2.4 для систем SMP (symmetric multiprocessing). «Хорошая SMP-масштабируемость в ядре стала возможной благодаря очень многим мелким шагам и тщательным проверкам, — сказал он. — Главная цель ядра 2.4 заключалась в достижении масштабируемости корпоративного уровня».

Zero-copy networking позволяет драйверу сетевой карты извлекать данные, которые она должна переслать, непосредственно из дискового кэша ядра или из буфера пространства памяти пользователя. До сих пор ядру приходилось предварительно копировать данные из дискового кэша в отдельный сетевой буфер.

Функции affinity связывают системные объекты, такие как исполняемый процесс или прерывание, с определенными CPU, что обеспечивает большую отдачу от каждого CPU.

Wake-one scheduling — это важное усовершенствование, повышающее эффективность мультипроцессорных серверных приложений. В Linux 2.2 все процессы, ожидающие каких-нибудь внешних данных (например, сетевого трафика), активизируются при поступлении любых данных. Так как запросом управляет только один процесс, то остальные, не обнаружив «своих» данных, тут же возвращаются в режим ожидания. В Linux 2.4 активизируется только один процесс, что создает экономию циклов CPU.
Обсуждение и комментарии

Злобный
22 Jun 2001 7:34 PM
Rad Hat - убивает Apache !
Rad Hat - убивает MySQL !
.
.
.
.
.
Rad Hat - убивает Linux ! ;)

Классно !
 

Garic
22 Jun 2001 7:37 PM
La,La,La,La...
 

AT - 220220pager.icq.com
23 Jun 2001 3:40 PM
Лажа ето все.

select(), а не потоково основаные вебсервера давно были уже.
А вот с разделением памяти между диском и сетевым стеком они они таки продвинулись. До сих пор были идеи оптимизации только одного сетевого стека, не всего вместе.

Да и ксати- "В Linux 2.2 все процессы, ожидающие каких-нибудь внешних данных (например, сетевого трафика), активизируются при поступлении любых данных", чушь - планировщик ресурсов зачем вообще делася ??
 

Pers
25 Jun 2001 9:06 AM
особенно интересно когда в tux, встроенный в ядро, найдут ошибку. и не хороший дядька получит права ядра.
Такой подход кажется в NT.
 

Den
25 Jun 2001 10:53 AM
Nu, konechno - esli Web server zapixnut' v kernel, navernoe, pobystree budet. Tol'ko kak tam naschet razdeleniya applikatziy i OS ? Pomnitsya, MS sdelal eto s IE - tak im vse pinkov ponadavali. A Red Hat - mojno! A Apacham tak i nado - process per-connection ?..
 

Оптимист
25 Jun 2001 1:42 PM
Нормально. Люди подумали перед тем как делать. Уже не над протоколами думают, а над реализацией. Закономерный этап. Оборотная сторона - MS опять украдет эти идеи, как всегда делала, и начнет за деньги втюхивать как свои достижения.
Да и апашники скорее всего тоже не будут сложа руки сидеть - так что кто кого - это надо еще посмотреть :-)
 

Snake - tomilinrambler.ru
25 Jun 2001 1:52 PM
Теперь фразы

"За секурность!
За модульность!
За структурность!"

следует воспринимать не как цели, а как шутки ;-(
Обидно, когда правильные идеи бросают ради рекордов.
Плакать надо, а не радоваться...
 

Alex - lizard-AntiSpamnstl.nnov.ru
26 Jun 2001 11:14 AM
RedHate... Идиоты. Встраивать в ядро веб-сервер, работающий с динамическим контентом - рыть себе могилу. Это же огромнейший потенциальный exploit! Тем более, учитывая "славу" кореженых Red Hate ядер... Сначала портачат, а потом дыры в пол-системы залатывать пытаются.
Хотя, про динамический контент там только одно упоминание ;) Не факт, что он с ним нормально работает. Тогда сравнивать вообще некорректно.
Кстати, парсер для http (то, что здесь назвали kernel-level веб-кэш) уже давно появился в ядре у FreeBSD, а не только у AIX. И еще вопрос - а с каким Apache сравнивали? 1.3.x или 2.0 ? Судя по описанию работы с threads - 1.3. А про 2.0 забыли? Или "благоразумно" исключили из тестирования? ;)) Зато как круто все выглядит!! Они бы еще с CERN HTTPD сравнили...
 

vIv
26 Jun 2001 10:50 PM
Предлагаю сорокагигабайтный кэш сквида тоже засовывать в область ядра - будет потрясающий рост скорости работы шквида!
 

Dmitry Grigorovich - odipconstulant.com
28 Jun 2001 10:36 AM
To vlv: не будет
 

dimonb - dimonbbeep.ru
11 Sep 2001 12:25 PM
эт.. эт они клева придумали... это уже у ред хета какие-то маздайные подходы: "решение на один раз".. надежность... а что нам надежность, давайте KDE2 ускорим таким образом... что-то мне не нравится его скорость... и вообще w9X самая продвинутая в этом плане :)))

они наверно думают, что написали идеальное приложение, которое глюкать не будет??.. думаю серьезнаю контора в гонке за скоростью купит еще один сервер, а не поставит сомнительное решение от RedHat или M$

PS. теперь у меня есть полное право их сравнивать :((((
 

Noname
11 Sep 2001 2:03 PM
Просто инвесторы RedHat хотят получить свои денежки назад с прибылью, а отсюда подход к разработке софта такой-же, как и у M$. Вот она - проза жизни! А вы все в облаках витаете. RedHat стала коммерческой компанией по выпуску коммерческого софта. Берите пример... ;-)
 

hotcooler
14 Oct 2001 6:40 PM

Люди, оно же сказано неполноценный...без сесеэль и все такое...и может перенаправлять все на Apache , тем сводя свою производительность туда-же или менее...когда он будет полноценный..пусть еще сравнят...

........ на платформе x86 (486DX2\24edo\mb_noname\НЖМД WD2.4\D-link62**_LPT-EthernetAdapter)
 

hotcooler
14 Oct 2001 7:03 PM
Вообще идея хорошая: на пингвине запускаются виртуальные ядра (как-раз 2.4) в одно сквид в другое вэбсервер в третье ssl отдельно....в четвертое доунгрэйд до ядра 2.2, чтоб "пахали" "дрова" под гигабит-девайс(производство г. Зеленоград)......в пятом будут отдельно умирать миднайт-командиры и реализации нфс для пингвина...
 

 

← май 2001 18  19  20  21  22  25  26  27  28 июль 2001 →
Реклама!
 

 

Место для Вашей рекламы!