Comments 32
Ни версий ОС(кроме винды, можно было и 2012 взять core), ни соотвествующих оптимизаций для малого количества памяти мы так и не увидели, из пальца всё.
Версии следующие (последние стабильные на момент ~20 дек 2012):
Debian-6.0.6-i386,
FreeBSD-9.0-RELEASE-i386,
CentOS-6.3-i386,
OpenSUSE-12.2-i586,
Ubuntu-12.10-server-i386.
Оптимизировать я изначально не планировал, хотел оценить версии «из коробки».
Debian-6.0.6-i386,
FreeBSD-9.0-RELEASE-i386,
CentOS-6.3-i386,
OpenSUSE-12.2-i586,
Ubuntu-12.10-server-i386.
Оптимизировать я изначально не планировал, хотел оценить версии «из коробки».
Тогда не объективно.
Ну почему не объективно? Если сравнивать «скорость ОС из коробки с нулевым тюнингом» — тест вполне объективен. Любой тест, это, в первую очередь сценарий, разработанный под конкретную задачу. И тестировать надо не на сферических конях, а на именно том наборе условий, который нужен персонально вам.
Для из коробки тест объективен, но для использования в рабочем окружении — не очень, правильная конфигурация может много изменить.
Я и не говорил, что это объективный нагрузочный тест для реальной нагрузки. Начнем с того, что любая нагрузка индивидуальна. У кого-то много очень дешевых транзакций и ему важна только скорость (соцсети). У кого-то наоборот — транзакции медленные, но очень дорогие (онлайн-магазин). Нагрузка будет различаться радикальнейшим образом. Вывод — тестировать надо в условиях, максимально приближенных к вашим реальным задачам. Тест «сферический вебсервер на сферическом VDS» ценность для специалиста имеет близкую к нулю. Этот тест в первую очередь для тех чайников, которые хотят вдс с вордпрессом и не хотят головной боли и читать умные книжки по точной настройке. Другие у людей приоритеты, это нормально :)
Сам характер тестирования (PHP + Apache :) ) на это намекает преявнейшим образом, прям ярче некуда.
Сам характер тестирования (PHP + Apache :) ) на это намекает преявнейшим образом, прям ярче некуда.
Спасибо за тест!
Не могли бы вы подписать под диаграмами, в каких единицах меряется, и какой результат лучше — больший или меньший?
Тем, кто уже прочитал, это не поможет, но новым читателям будет легче понять, что за столбцы показаны.
Не могли бы вы подписать под диаграмами, в каких единицах меряется, и какой результат лучше — больший или меньший?
Тем, кто уже прочитал, это не поможет, но новым читателям будет легче понять, что за столбцы показаны.
>Версии AMP’а примерно все одинаковые, устанавливались последние версии стандартными менеджерами пакетов (linux)
> Оказалось что на OpenSUSE и Ubuntu установлена MySQL 5.5.xx, а на всех остальных 5.1.xx.
>Решил глянуть на файловую систему: на Debian ext3, на Ubuntu ext4, но на CentOS опять же ext4.
Очень необъективное тестирование, я бы не рискнул на его основе что-то там выбирать. Наверняка отличия по тестам были вызваны неравномерностью установок, отличиями в ядрах, ФС, версиях пакетов.
> Оказалось что на OpenSUSE и Ubuntu установлена MySQL 5.5.xx, а на всех остальных 5.1.xx.
>Решил глянуть на файловую систему: на Debian ext3, на Ubuntu ext4, но на CentOS опять же ext4.
Очень необъективное тестирование, я бы не рискнул на его основе что-то там выбирать. Наверняка отличия по тестам были вызваны неравномерностью установок, отличиями в ядрах, ФС, версиях пакетов.
FreeBSD конечно хорош, но по визуализации пока отстает. KVM или XEN не поставишь. А внутри Jails только подобные ОС можно навесить.
Для виртуализации хорошо использовать CentOS или Debian.
Для виртуализации хорошо использовать CentOS или Debian.
>Большое отличие в способе установки ПО
пакеты во фре тоже есть (pkg_add -r) но это не BSD путь.
пакеты во фре тоже есть (pkg_add -r) но это не BSD путь.
Автору на заметку:
Вот это какой-то жжжутчайший велосипед. Существуют специализированные утилиты, например apache benchmark или же siege, которые используются для подобного рода тестов.
Зачем лепить сюда Wordpress если в коде скрипта для теста используется простой insert в цикле в отдельно взятую таблицу? Вообще говоря внутри Wordpress-а при создании поста помимо вставки записи в таблицу wp_posts присутствует масса других оверхедов. Почему была выбрана именно эта таблица? почему с таким же успехом не создать какую-то другую таблицу, в имени которой не фигурировал бы Wordpress?
это классика… Сделать 1000 раз select равносильно тому чтобы проверить query cache например. Смысл в таком дико искусственном тесте?
Иии что? Как это связано с производительностью на отдельно взятом дистрибутиве? а вы пробовали ставить MySQL не из пакетов, а собирать вручную из сорцов? Уверен что в этом случае производительность во всех вышеприведенных тестах будет совершенно другая. И, кстати, что мешает самому на любой unix-like ОСи собрать последнюю версию MySQL из исходников?
Дело не в производительности. В 90% случаев дистрибутив выбирает админ, и выбор этот зависит по большей части от того, в какой ОС он больше всего прошарен. Debian — это в первую очередь стабильность (если ориентироваться на main-репозиторий), CentOS — аля RedHat, а тут уже куча своих плюшек. Зачем сюда лепить мифическую производительность — вообще непонятно.
Затем в футер странички добавляется js-код, который по window.onload перезагружает страницу. Суть теста заключается в подсчете времени загрузок 50 страниц. Перезагрузка происходит 2 вариантами: location.href=’/’ и location.reload(true). Когда выставляем параметр forceGet в true, браузер перезагружает все ресурсы на страничке (картинки, стили, скрипты). Тест через file_get_contents: на ОС-хосте выполняется php-скрипт, который загружает 50 страниц с тестируемой машины посредством функции file_get_contents.
Вот это какой-то жжжутчайший велосипед. Существуют специализированные утилиты, например apache benchmark или же siege, которые используются для подобного рода тестов.
Была взята таблица wp_posts. Операции повторяются 5000 раз.
Зачем лепить сюда Wordpress если в коде скрипта для теста используется простой insert в цикле в отдельно взятую таблицу? Вообще говоря внутри Wordpress-а при создании поста помимо вставки записи в таблицу wp_posts присутствует масса других оверхедов. Почему была выбрана именно эта таблица? почему с таким же успехом не создать какую-то другую таблицу, в имени которой не фигурировал бы Wordpress?
Все же номинальных победителей определим: Запись CentOS, чтение OpenSUSE.
это классика… Сделать 1000 раз select равносильно тому чтобы проверить query cache например. Смысл в таком дико искусственном тесте?
Оказалось что на OpenSUSE и Ubuntu установлена MySQL 5.5.xx, а на всех остальных 5.1.xx.
Иии что? Как это связано с производительностью на отдельно взятом дистрибутиве? а вы пробовали ставить MySQL не из пакетов, а собирать вручную из сорцов? Уверен что в этом случае производительность во всех вышеприведенных тестах будет совершенно другая. И, кстати, что мешает самому на любой unix-like ОСи собрать последнюю версию MySQL из исходников?
все они работают на Debian. Но почему именно он? Не знаю, возможно, эта ось более популярна
Дело не в производительности. В 90% случаев дистрибутив выбирает админ, и выбор этот зависит по большей части от того, в какой ОС он больше всего прошарен. Debian — это в первую очередь стабильность (если ориентироваться на main-репозиторий), CentOS — аля RedHat, а тут уже куча своих плюшек. Зачем сюда лепить мифическую производительность — вообще непонятно.
Спасибо за ссылки, изучу. Насчет тестов — согласен, велосипед, но было интересно сделать его.
Из сорцов не ставил, но обязательно попробую.
По поводу таблиц в БД Wordpress'а: не думаю что принципиально, использовать существующую или создать свою.
Из сорцов не ставил, но обязательно попробую.
По поводу таблиц в БД Wordpress'а: не думаю что принципиально, использовать существующую или создать свою.
Debian — не «стабильность», а «ванильность», я бы так сказал =)
Жесткие debian policy про сборку пакетов, про пути конфигов, про дефолтные конфигурации, жесткое модерирование пакетов и многие подобные вещи — делают его любимым дистрибутивом тех, кто настраивает системы надолго. В принципе, убунта туда же (если речь не про десктоп) — там следят за обратной совместимостью путей/конфигов/etc.
В итоге — хорошая здоровая экосистема, за которой не нужно судорожно читать change-логи. Ну сменились версии, ну новый mysql, ну новый nginx. Скопирую конфиги — всё продолжит работать. Перенесу данные — всё продолжит работать. (быдлокод, который не переносился на php 5.3, например, мы в рассчет не берем).
И ещё одно следствие — мануалы от etch'a до сих пор актуальны. А не так давно мне снова пришлось заглянуть в очень древний мануал по woody (что-то там про установку и тюнинг apache2) — и он всё равно был актуален до единой строчки (разве что пакеты уже не нужно было через задний проход в систему приносить). Соответственно, актуальных мануалов полно, новичку разобраться легко, когда новичек переходит в стан гуру — он так и остается на дебианах/убунтах. А новые новички приходят к гуру за советом, те им советуют дебиан. Ну и так далее.
Короче всё это к тому, что стабильность в дебиане в этом моменте никакой роли не играет.
Жесткие debian policy про сборку пакетов, про пути конфигов, про дефолтные конфигурации, жесткое модерирование пакетов и многие подобные вещи — делают его любимым дистрибутивом тех, кто настраивает системы надолго. В принципе, убунта туда же (если речь не про десктоп) — там следят за обратной совместимостью путей/конфигов/etc.
В итоге — хорошая здоровая экосистема, за которой не нужно судорожно читать change-логи. Ну сменились версии, ну новый mysql, ну новый nginx. Скопирую конфиги — всё продолжит работать. Перенесу данные — всё продолжит работать. (быдлокод, который не переносился на php 5.3, например, мы в рассчет не берем).
И ещё одно следствие — мануалы от etch'a до сих пор актуальны. А не так давно мне снова пришлось заглянуть в очень древний мануал по woody (что-то там про установку и тюнинг apache2) — и он всё равно был актуален до единой строчки (разве что пакеты уже не нужно было через задний проход в систему приносить). Соответственно, актуальных мануалов полно, новичку разобраться легко, когда новичек переходит в стан гуру — он так и остается на дебианах/убунтах. А новые новички приходят к гуру за советом, те им советуют дебиан. Ну и так далее.
Короче всё это к тому, что стабильность в дебиане в этом моменте никакой роли не играет.
Поддержу. Плюс — все работает «из коробки». В итоге стоимость обслуживания ниже.
Тоже юзаю в основном Debian. Нравиться стабильность. Один раз настроил и забыл. Легко обновляется. Нет проблем с виртуализацией — пару минут и новая виртуалка уже работает (имею ввиду собственную ферму в ЛВС). Однако у BSD есть несколько интересных вещей, которые хочется юзать. Взять хотя бы его ядро. ИМХО но ядро FreeBSD приятнее кастомить чем Linux. А еще там есть ZFS, NPF(netbsd), netgraph. Да и сами дистрибутивы более монолитны. А вот с виртуализацией, как мне показалось, не очень (как у FreeBSD9 не знаю, а вот FreeBSD8 на Xen не очень быстро работала даже с использованием модифицированного ядра. Debian — просто летает). Ну и конечно система портов. Я люблю собирать ПО из исходников, но когда у тебя несколько десятков серверов, да еще и в виртуальной среде, то на это может уйти куча времени.
Поэтому я соглашусь с мнением что BSD лучше ставить на реальное железо в небольших количествах. А Debian и его производные в виртальной среде.
Поэтому я соглашусь с мнением что BSD лучше ставить на реальное железо в небольших количествах. А Debian и его производные в виртальной среде.
UFO just landed and posted this here
«Как я тестировал дефолтные настройки демонов и sysctl в FreeBSD, 4 дистрах Linux и Win».
Садитесь, два.
Садитесь, два.
А зачем в век PaaS вообще тестировать производительность операционных систем, когда всех интересует производительность стека?
ТСу: установи себе генту — будет тебе счастье!
ОС в качестве веб-сервера
Веб-сервер — это не всегда Apache+MySQL+PHP. Точнее, даже, в последнее время, — почти никогда.
Sign up to leave a comment.
Тестируем ОС в качестве веб-сервера