Apache,PHP, MySQL on FreeBSD/Linux/Solaris benchmark

На доскональное знание данной темы, не может претендовать, пожалуй ни один спец, из ныне живущих на земле. ;-)
Так поможем друг другу.

Модераторы: Trinity admin`s, Free-lance moderator`s

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 31 мар 2006, 13:15

SysR
Мда. Уважаемый. Либо измените тон Ваших постов (вежливее пожалуйста), либо будете забанены.
Ваше мнение выражено в хамской форме, я бы сказал.
Если лично для Вас тесты бесполезны - не пишите в ветку, пожалуйста.

SysR
Junior member
Сообщения: 5
Зарегистрирован: 30 мар 2006, 17:06

Сообщение SysR » 31 мар 2006, 13:24

a_shats писал(а):Мда. Уважаемый. Либо измените тон Ваших постов (вежливее пожалуйста), либо будете забанены.
Ваше мнение выражено в хамской форме, я бы сказал.
Если лично для Вас тесты бесполезны - не пишите в ветку, пожалуйста.
Прошу просчения, больше писать небуду, можете мой профиль удалить. Так как на таких НЕКОМПЕТЕНТНЫХ форумах я не обычно не сижу, мне за державу обидно.
Один совет: изучайте то что тестируете.

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 31 мар 2006, 13:28

По моему тесты пингвина и солярки никакого осуждения не вызвали. Так что они наверно полезны. Про фрю - ну что, еще раз повторить дисклаймер?

KeNt
Junior member
Сообщения: 1
Зарегистрирован: 31 мар 2006, 09:32
Контактная информация:

Сообщение KeNt » 31 мар 2006, 15:05

Мое субективное IMHO
надо провести тест фри заново
ставить софт из портов
консультироваться по конфигу ядра на форуме, если уж сами неуверенны

в основном поддерживаю SysR

з/ы/ еще бы результаты мастдайки выдали бы
так для общего развития

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 31 мар 2006, 15:17

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

Винда слила напрочь.

Мнение - пусть остается какое угодно, нам собственно интересна только конструктивная критика, а не пальцы.

Andrey Y. Ostanovsky
Advanced member
Сообщения: 103
Зарегистрирован: 04 окт 2004, 15:07

Сообщение Andrey Y. Ostanovsky » 31 мар 2006, 15:17

SysR писал(а):
net.inet.tcp.delayed_ack=0
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
Вот кусок моего sysctl.conf что касается сети.
Маловато будет, однако.:)

Код: Выделить всё

kern.ipc.somaxconn=2048
kern.ipc.maxsockbuf=16777216
net.inet.tcp.sendspace=1048576
net.inet.tcp.recvspace=1048576

Terol
Junior member
Сообщения: 2
Зарегистрирован: 31 мар 2006, 15:33

Сообщение Terol » 31 мар 2006, 15:42

gs писал(а): ....
Винда слила напрочь.
....
Простите, а правильно ли я понял что под Windows вы тестировали точно такую же конфигурацию:
# Apache 1.3.34
# MySQL 4.1.18
# PHP 4.4.2
# Форум phpBB 2.0.19 150000 сообщений

Ingoa
Junior member
Сообщения: 1
Зарегистрирован: 31 мар 2006, 19:10

Сообщение Ingoa » 31 мар 2006, 19:20

В общем как показывает практика для Linux и FreeBSD тесты на файловых системах, TCP стек, фильтры и.тд. достаточно похожи и значения отличаются на 10-30% максимум. Тут удивляют РАЗЫ....
Самый пресамый тюнинг дает тоже около 10-20% в отличие от нетюнингованной машины.
Скорее всего, что это беда FreeBSD при работе с многопроцессорными машинами или проблема именно с 64-битной AMD, но скорее всего именно с многопроцессорностью...
Для однопроцессорных машин таких различий не наблюдается. Проверялось неоднократно.

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 31 мар 2006, 19:26

Наверно. Только ведь как раз и хотели потестить машины не энтрилевел. Во второй части будет сравнение на том же тесте разных архитектур - АМД - классикСпарк - Ниагара - возможно ксеон. Только вот побаиваемся выкладывать - если уж банальная фря народу покоя не дает, то что будет после публикации не очень приятных результатов тяжелых машин. Можно и на гнев Великого САНА нарваться :)

sanek1978
member
Сообщения: 32
Зарегистрирован: 17 май 2003, 15:36

Сообщение sanek1978 » 01 апр 2006, 00:58

Наконец-то я увидел ваш форум!
KeNt еще бы результаты мастдайки выдали бы
так для общего развития
Чтобы набежали мастдайщики и говорили что надо в реестре править? Мне вообще не интересно что у этого зверька в кишках. Мастдайка именно СЛИЛА. Кто-то ее рассматривает серьезно как сервер, кроме как для 1С? :)
smb - больше коннектов держалось бы в очереди в ядре...
Ну таймауты бы увеличились, кому легче стало бы?  :) Не было процессорного времени для работы пхп скриптов, куда его подевала фря и пытались понять.
Ты точно уверен что целесообразно использовать ULE? Пока пытался разобратся с проблемой, нашел ряд комментов, что мускул с ним гаррантированно дохнет.
Можно и на гнев Великого САНА нарваться
С классическим спарком не нарвемся, по предварительным оценкам он держит нагрузку лучше Newisys в разы. Я до сих пор сомневаюсь выкладывать результаты или нет, т.к. эти железки совсем не для веб нагрузок и никто в здравом уме их покупать не будет для веба.  Это как проводить соревнование жигулей с камазом, едет теже 90км\ч, но с 10т вместо 300кг. Пока склоняюсь больше к "не выкладывать". Удел веба мелкие сервера 1-2, макс 4 ядрышка, даже 8 что мы взяли - перебор.
анальная фря народу покоя не дает
можно элементарно забить, был ряд конструктивных комментариев (спасибо за них), их проверим если будет время и железки.

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

На создание стенда надо:
- собрать как вам кажется оптимальным ядро AMD64 линуха/фри (пусть 30 минут)
- собрать как вам кажется оптимальным апач, мускул, пых-пых соответствующих версий (пусть еще час). Ставить nginx, zend и т.п. не надо. Ежу понятно что будет быстрее, но цель проверить работу ОС, а не доказать что эти продукты улучшают производительность.
- залить уже готовую базу (ну еще 15 минут).
- для оценки запустить тестилку на паре прогонов 256 и 1024 треда. Желательно на jre 1.5, она сильно лучше работает с потоками (хватит 1 часа)
- выложить конфиги и результаты (15 минут)
- ждать пока другие обгадят твои результаты (10минут)
Итого от силы 3-4 часа. На флейм времени было потрачено больше :)

smb-
Junior member
Сообщения: 19
Зарегистрирован: 12 янв 2006, 20:20

Сообщение smb- » 01 апр 2006, 01:31

sanek1978 писал(а):Наконец-то я увидел ваш форум!
smb - больше коннектов держалось бы в очереди в ядре...
Ну таймауты бы увеличились, кому легче стало бы?  :)
Эм, как я понимаю, уменьшились бы, возможно, в тесте на отдачу кучи одновременных коннектов и измерения задержки фряха бы выправилась...
sanek1978 писал(а): Не было процессорного времени для работы пхп скриптов, куда его подевала фря и пытались понять.
Ты точно уверен что целесообразно использовать ULE? Пока пытался разобратся с проблемой, нашел ряд комментов, что мускул с ним гаррантированно дохнет.
Идея использования ULE и всего прочего заместо 4.4BSD в том, чтобы добиться именно нормальной работы в SMP - с 4.4BSD работать будет, и стабильно - но про perfomance можно подзабыть.....4.4BSD планировщик не создан для работы в SMP, у него кучи Giant Lock-ов, он не умеет кидать threads между процессорами - а без этого у вас апач нормально не отмасштабируется - ибо будет привязка (процесс -> CPU)....По факту - на одной из наших машин загрузка мускула доходила до 50% - при машине dual xeon получается полностью занят один проц....Второй проц простаивал....Фряха - 4.11, планировщик => 4.4BSD...Вот эта обратная сторона медали стабильности оного планировщика(сейчас, впрочем, переделали запросы к базе, благо есть возможность, обновлили сам MySQL, полегчало :) )

Окончательных выводов не делаю и полнее тему пока врядли раскрою - искал и ищу наиболее полную документацию с комментариями по этому сабжу и по сей день, но идея правильная.....
sanek1978 писал(а):
Можно и на гнев Великого САНА нарваться
С классическим спарком не нарвемся, по предварительным оценкам он держит нагрузку лучше Newisys в разы. Я до сих пор сомневаюсь выкладывать результаты или нет, т.к. эти железки совсем не для веб нагрузок и никто в здравом уме их покупать не будет для веба.  Это как проводить соревнование жигулей с камазом, едет теже 90км\ч, но с 10т вместо 300кг. Пока склоняюсь больше к "не выкладывать". Удел веба мелкие сервера 1-2, макс 4 ядрышка, даже 8 что мы взяли - перебор.
анальная фря народу покоя не дает
можно элементарно забить, был ряд конструктивных комментариев (спасибо за них), их проверим если будет время и железки.

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

На создание стенда надо:
- собрать как вам кажется оптимальным ядро AMD64 линуха/фри (пусть 30 минут)
- собрать как вам кажется оптимальным апач, мускул, пых-пых соответствующих версий (пусть еще час). Ставить nginx, zend и т.п. не надо. Ежу понятно что будет быстрее, но цель проверить работу ОС, а не доказать что эти продукты улучшают производительность.
- залить уже готовую базу (ну еще 15 минут).
- для оценки запустить тестилку на паре прогонов 256 и 1024 треда. Желательно на jre 1.5, она сильно лучше работает с потоками (хватит 1 часа)
- выложить конфиги и результаты (15 минут)
- ждать пока другие обгадят твои результаты (10минут)
Итого от силы 3-4 часа. На флейм времени было потрачено больше :)
Кстати, если уж у нас тут такие дебаты по MySQL - можно отдельно для него синтетику погонять какую-нибудь :) sysbench-евскую(или что посерьезней) OLTP-шку, например...Я как-то гонял для теста дома, нормально, имхо, некоторое представление дает...Картина при одновременных коннектах 2-4-8-16-32-...1024 может быть интересной...Впрочем, я-то тестил на одном камне - очевидно ничего реально интересного :)

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 20:24

Что тут сказать, коллеги...

Печальное зрелище. Обзор сырой, т.к. глубины знаний по FreeBSD автор не продемонстрировал. Не то чтобы все плохо, но, возможно, это не самая близко знакомая ему система из представленных. Поэтому и результат для этой ОС он получил особенно некорректный и нерепрезентативный. Проще говоря - мерял он на самом деле вовсе не то, что собирался. В меньшей степени это и остальных 2 представленных в статье UNIX-систем касается.

Прошу сразу меня простить и на краткость не обижаться, мало времени - постараюсь конспективно, но конструктивно наметить то, что сделано не так.
  1. Не могу выкачать домой 50-мегабайтную базу, долго очень будет, но т.к. формат базы не указан, а это важно, предположу - а меня поправят, если я ошибаюсь, что база у Вас в формате MyISAM. MyISAM КАТЕГОРИЧЕСКИ противопоказан при работе под большими нагрузками. Все разрабатывают всякие форумы в этом формате, т.к. он дефолтный, так проще и никаких проблем при разработке они, ессно, увидеть не могут. Под нагрузкой ситуация меняется - я подчеркиваю это - КАЧЕСТВЕННО, а не количественно.
  2. Прошу меня простить, что не привожу здесь ссылки на первоисточники, но общеизвестно то, что под фрей с майисамным мускулем вы будете измерять фактически скорость работы файловой системы. Причем в очень неэффективном режиме работы. База данных все-таки. И на графике у вас при росте нагрузки сначала все хорошо, потом она наедается.
  3. Неотключенный дебуг в ядре пугать никого особо не должен. От дебуг-символов еще никто не умирал. Включение SMP это хорошо. Оптимизировать ядро надо - выкинуть лишние драйвера, процессор оставить только один - старший допустимый... это все просто. Ядро меньше весит и быстрее работает.
Нужно.
  1. Взять уже FreeBSD 6.1 PreRelease (BETA4) или релиз, если успеет выйти. Она лучше работает - ребята там все же движутся в верном направлении. И она уже вполне готова в дело. И 64 бита быстрее работает, так что не надо тестировать i386 рядом с 64битным Солярисом. Надо аккуратно все собрать под 64 бита и все. Есть вещи, с которыми это не очень просто - но апач и мускуль вполне себе соберутся.
  2. Аккуратно разобраться с ядром. Нетюненое ядро - какой интерес? Кто ж на таком работает? Сравнить из чисто академического интереса? Ну, если времени не жалко... Шедулер ULE - я слышал, что он еще не вполне готов, трогать его без толку. Хотя ситуация может и измениться, и скоро... IPV6 проще вообще не трогать - есть еще над чем подумать. Неиспользуемые драйвера надо выкинуть ВСЕ. NFS никому не мешает. Кстати, может быть интересно использовать для всех тестируемых систем один общий внешний NFSный сторадж - очень частая на практике ситуация.
  3. Далее. Все собирать из портов. Убедиться, что все собирается с оптимизацией, под нужный проц и с правильными опциями.
  4. Сконвертировать базу в InnoDB. Full-text indexes форум phpBB не использует, так что сконвертируются все таблицы (в отличие от IPB, где в 2 самых нагруженных - порядка 50% нагрузки - нужно было бы отказаться от них). Далее нужно будет добавить в базу phpBB ряд индексов, которых ему реально не хватает - примерно 3-4-5 индексов - анализ медленных запросов поможет. Разработчики форумов не работают с экземплярами под такой нагрузкой, им многое просто не видно и не очевидно. Разнице показываемых результатов вы поразитесь. Когда мне показали графики загрузки одной системы с множеством очень посещаемых форумов до и после - я поразился.
  5. Внедрите nginx. Ту же работу у вас будет делать гораздо меньшее количество апачей и гораздо эффективнее. Памяти много - буферами можно будет не жадничать.
  6. Внедрите к php модуль расширения eAccelerator (кеширование php и байт-кодов, кэш общий для всех детей данного мастер-процесса апача), а еще лучше в связке с php Encoder'ом (предварительная прекомпиляция с оптимизацией). Лично недавно внедрил nginx (просто в режиме акселерированного некеширующего проксирования, даже статику пока им не раздавал) и eAccelerator (просто, без енкодера) на системе, где основную нагрузку создавали большой php-шный сайт и форум на IPB 2. Использование памяти уменьшилось втрое, зарузка про процессорному времени в 2.5-3 раза, загрузка по LA в 3-4 раза, время реакции в часы пик - на порядок-полтора. Памяти у вас много, в кэш все влезет, что будет надо.
  7. В процессе тестирования мониторьте
    • CPU LA
    • CPU Total/Interrupt Times (для Solaris - Total/System Times)
    • Memory/Swap usage (для FreeBSD нужно Inact+Free, для Solaris нужно учитывать специфику ее обращения со свопом, нужно извлечь, сколько там реально лежит). Памяти у вас много, своп должен показывать 0.
    • Disk Load, iops, In/Out (если средняя (!) величина за дежурные 5 минут будет 50-70 - считайте, что Вам недостаточно хорошо, если 80-100 и выше - считайте, что просто плохо)
    • Disk Load, throughput, MPps In/Out (Необходимы оба графика! Вы можете - и скорее всего, должны - выйти на насыщение по операциям гораздо раньше, чем диски начнут захлебываться по пропускной способностями - клиент, веб-сервер, форум и база взаимодействуют тучами мелких пакетиков вразнобой, а не большими потоками подряд, доступ у базы гораздо более random чем sequential, тем более в вашем варианте, и операции ввода-вывода гораздо важнее объемов).
    • LAN Traffic, pps, In/Out
    • LAN Traffic, Mbps, In/Out
    Без мониторинга и графиков тесты не очень дорого стоят. Вы просто не знаете, что на самом деле происходит, а вам кажется, что знаете - и вы рассказываете об этом другим. И внутреннюю жизнедеятельность мускуля стоит помониторить. А без этого вы так и не будете знать, в которое именно узкое место вы уперлись, и не зная это, будете не сравнивать между собой 3 системы, а измерять толщину 3 бутылочных горлышек, вам неизвестных.
  8. Попробуйте перейти от RAID1 к RAID10 . Особый экстремизм - раздробить базу на части и разложить вдумчиво по разным независимым шпинделям без всяких RAIDов.
  9. И вот после всего этого надо перемерять все 3 системы. В этих новых условиях - все 3 системы. Это не очень маленькая работа, но вы ведь не ожидали, что корректно оттестить сложную проблематику будет быстро и легко? А так, как щаз - "грустное зрелище, душераздирающее зрелище". 3 системы как 3 сферических коня в вакууме, запущены в режиме, для которого не предназначены под такими нагрузками, как сказали бы физики "за границами применимости выбранной абстрактной модели". Из них одна система - сильно за границей.

    Это все равно как залить в 3 суперкара 3 разных сорта прямогонного бензина, масло у всех слить, родной антифриз заменить на "савейский" тосол (поддельный, с авторынка) - а потом в попытке побить рекорд скорости выяснять, который из 3 несчастных суперкаров быстрее едет. Top Gear, одно слово...
Поэтому результаты всех 3 систем в той или иной степени некорректны. А одной - некорректны сильно. Все 3 спокойно себя чувствуют под невысокой нагрузкой, а потом вы экстраполируете это на высокую нагрузку, для которой вы системы не приспособили, под которой они в неприспособленном виде не обязаны показывать по-настоящему хорошую работу - а потом удивляетесь, что результаты странные.

Ничего странного. 3 системы, недоточенные под интенсивную задачу. Двум нехорошо, одной плохо. Ну и что с того? Никто их в таком виде под такой нагрузкой не использует (просто не может :lol: ), никаких выводов сделать нельзя. Для чего тратилось время? Почему не потратить больше времени, чтобы результат был полезен? И оправдал бы все усилия? А так-то пока не оправдал никаких! Вы просто не то меряли. Говорю вам как человек, профессионально знакомый с техникой физического эксперимента. У вас методические погрешности. Результат системно и закономерно отличается от должного. Со всем уважением, коллеги, без обид!

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

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

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 21:07

2 smb-

Giant Lock'и постепенно уходят, только в некоторых подсистемах и драйверах остаются. Кстати, на адаптековском сказике до сих пор есть! Вот цитата с системы FreeBSD 6.1 BETA4

Код: Выделить всё

ahc0: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe400-0xe4ff mem 0xfebfe000-0xfebfefff irq 16 at device 3.0 on pci4
ahc0: [GIANT-LOCKED]
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc1: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff irq 17 at device 3.1 on pci4
ahc1: [GIANT-LOCKED]
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Если у них в системе подобный контроллер - то просто труба. На то он и Гигантский Лок. Если процесс из юзерспейса делает сисколл, который войдет в такой драйвер - то другой юзерский процесс, может, еще и будет работать... пока не сделает какой-то (ЛЮБОЙ!!!) сисколл - а тогда будет курить бамбук, пока первый из ядра не выйдет и свой Giant Lock не снимет.

Неиспользуемые процессоры вполне могут быть намеком на то, что мы проводим время в ожидании, во взаимных блокировках. Вместо того, чтобы работать, сидим и глазки пучим.  :roll: Или еще на что-то... Это уже тонкие материи, но быть такого в норме не должно...



В статье заявлен первый Apache, а не второй. Apache 1.3.34 . Он вообще не тредится, он работает в префорке! Это у второго, у apache-2 есть режимы и worker с тредами, и pre-fork - как и раньше. А процессы чайлдов апача никто по отдельным ядрам планировщику раскидывать не мешает.

=======================

Просьба к автору, sanek1978.
Дайте полную спецификацию на тест-систему. Все. Не только процы, но и мать, модель, какие контроллеры в системе, все детально.  На чем висят диски? Какие сетевушки - модель, чипы?

Дайте, пожалуйста, полностью /var/run/dmesg.boot - может, среди драйверов устройств, по которым идет поток информации прии тесте, все же есть GIANT-LOCKED ... тогда на такой системе нельзя тестировать FreeBSD в рамках Вашего исследования - Вы просто не сможете корректно сравнивать результат с другими ОС, они по-другому реализованы, у них свои тараканы в голове... Скажите, нет ли чего подозрительного при работе в /var/log/messages
Последний раз редактировалось Landadan 01 апр 2006, 22:45, всего редактировалось 2 раза.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 21:38

gs писал(а):Наверно. Только ведь как раз и хотели потестить машины не энтрилевел. Во второй части будет сравнение на том же тесте разных архитектур - АМД - классикСпарк - Ниагара - возможно ксеон. Только вот побаиваемся выкладывать - если уж банальная фря народу покоя не дает, то что будет после публикации не очень приятных результатов тяжелых машин. Можно и на гнев Великого САНА нарваться :)
Делайте все корректно - и пусть тогда все хоть в пупке лопнут!  :P А так, вы выяснили, что что-то плохо, но не выяснили почему... Может, у вас контроллер дисковый такой, что во фре для него еще в драйвере джайант лок не убрали? И вы смените дисковый контроллер и сразу все системы подровняются, т.к. проблемная их догонит на раз?

Или еще в чем-то дело? Надо бы сначала подопытного джинна датчиками обвешать сверху донизу, да подобрать вариант аппаратуры и методику тестирования (!) так, чтобы для всех систем это было бы корректно одновременно (!). Иначе условия неравны. И все 3 (или сколько их будет) системы одинаково потюнить под задачу.

Апач очень плохо отдает ответ в сеть. Висит в памяти, жрет проц. Висит и жрет, пока клиенту ответ не отдаст. nginx за него это сделает лучше - получит ответ от апача, закроет коннект с бэк-ендом, Апач сможет сразу принимать новые запросы (а не ерундой страдать), а nginx докидает ответ клиенту и еще и keepalive обеспечит.

Апач очень плохо отдает статику (те же картинки и т.д.). Накладные расходы ужасные. Каждая одна картинка - один http-запрос, одно обращение к чайлду апача или порождение нового, если нет их свободных, а потом он полезет на диск, поскрипит мозгами и начнет эту картинку отдавать... И так каждому клиенту каждую чертову стрелочку, логотипчик и смайлик... Обратно же nginx в студию!

Апач тратит массу лишнего времени на загрузку с диска и компиляцию раз за разом выполняющихся скриптов - OS на деле ничерта не кеширует, он сам - если специально не заставить - тоже. eAccelerator + Encoder в студию!

Последовательно и тщательно избавьте Апач на ВСЕХ тестируемых системах от ВСЕЙ лишней работы - не его она! Его дело - выполнение php-шной логики . В самом узком смысле слова. ТОЛЬКО выполнение. Все остальное он делает очень плохо, ОЧЕНЬ. Потому, что большой, сложный и тяжелый, потому, что не для этого предназначен.

На малых нагрузках наплевать на все это. Но вы же не на таких нагрузках тестируете? А на больших вы гоняете систему в условиях, для которых она не предназначена. А из того, что системы с несвоими проблемами методом грубой силы справляются по-разному качественно и количественно, никаких выводов сделать нельзя. НИКАКИХ. Кроме того, что вы что-то не то меряете, чем то, что собирались. На этот вывод, полагаю, никто планов не строил.

Избавьте Апач от несвойственной ему работы, убедитесь, что в системах нет паразитных блокировок, которые искажают весь результат, создайте мускулю комфортные условия для работы, мониторьте все, чтобы ВИДЕТЬ, что вы ничего не пропустили - и все у вас будет в шоколаде. Высокосортном. Элитном. Вкусном - все полопаются от зависти.

И никто - ТОГДА - не оспорит результатов.

Это если вообще захотелось протестировать данную частную задачу (phpBB - Apache - MySQL - storage) не на кластере, а на одиночной высокопроизводительной системе.
Последний раз редактировалось Landadan 01 апр 2006, 22:38, всего редактировалось 1 раз.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

Landadan
Junior member
Сообщения: 9
Зарегистрирован: 01 апр 2006, 18:02

Сообщение Landadan » 01 апр 2006, 22:27

gs писал(а):По моему тесты пингвина и солярки никакого осуждения не вызвали. Так что они наверно полезны. Про фрю - ну что, еще раз повторить дисклаймер?
Первое неудивительно, полезность несомненна, а дисклеймер ничего не лечит. Или убирать вместе с дисклеймером, или доточить, чтобы явное несообразие в глаза не бросалось... всем...
==============================
KeNt писал(а):Мое субективное IMHO
надо провести тест фри заново
Все тесты. Мотивировка выше.
ставить софт из портов
ППКС!
консультироваться по конфигу ядра на форуме, если уж сами неуверенны
ППКС! И не только ядра. Никто из нас не родился со всеми теми знаниями, умениями и навыками, что сейчас имеет. И никто не выглядит хуже, чем должен, если только вопросы, которые он задает, правильные.

Когда-то я не знал половины того, что тут затронуто, но встали задачи - и я их раскопал. Когда-то я не верил в половину той разницы (качественной разницы) между девелопментом и промышленной нагрузкой, которую потом увидел на натуре и смог не только почувствовать, но и численно сравнить.
==================================
gs писал(а):Тест повторный проведем как я уже сказал (по крайней мере постараемся). На самом деле это далеко не все тесты - просто еще не готово.
Я боюсь показаться нахальным и/или вызвать Ваше разочарование и недовольство, но переделывать нужно гораздо больше, чем Вы, возможно, полагали.
Но по поводу тюнинга конфига, есть подозрение, что многократную разницу покрыть таки не удастся. Слишком круто.
Вы не вполне правы. Все (ВСЕ!) зависит от того, во что Вы уперлись. Если в какую-нибудь блокировку, то ее обход может дать многократную. Влегкую. Избавление системы от несвойственной ей работы даст кратность от 3-4 до 8-10 - и для всех систем. Это не дело, когда вместо полезной работы дорогущий сервер только тепловыделением занимается.
Правда я не очень представляю фрю на промышленной системе такого калибра
Это не аргумент. Я представляю и использую. И ОЧЕНЬ много кто использует.  Мне чаще всего стройность, удобство и стабильность важнее всего.
тут таки в основном солярка, аикс и начинающий внедряться линукс.
10ую солярку, x86/x64 в основном, шедевр индусов-программистов, этот Тадж-Махал программирования, им еще дотачивать и дотачивать, допиливать и допиливать... И драйвера дописывать, и много что доделывать, а детские ошибки (типа непоправленного LittleEndian/BigEndian при портировании на интел со спарка, из-за чего в России 2 раза в год система правит часы, улетая в другой век по времени и снося себе весь чердак напрочь) пора бы переставать делать. Патчей на нее как на винду. А кучу полезного софта от бэкапов до антивирусов для S10/X64 еще ждать и ждать. Я люблю эту систему и ценю во многих применениях, но если в ней поглубже покопаться, там много "интересного" спрятано. Все не без грехов.
Причины - в основном не технические, но от этого не менее веские.
У всех свои причины. Linux'ы входящие в Linux Community люди называют свободой и демократией, а часть не входящих - коротко бардаком и разносортицей. Каждому свое. В моей конторе пингвины вообще не используются - всех изжили. А кому-то они нужны позарез. Ради Бога.
Так что тесты фри по большому счету были чисто факультативные.
И зря Вы так!
Мнение - пусть остается какое угодно, нам собственно интересна только конструктивная критика, а не пальцы.
Я старался. Не судите строго.
Vadim A. Umanski
Panferova.Net.RU
Comcor-TV

Ответить

Вернуться в «Серверы - ПО, Unix подобные системы»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 16 гостей