The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: Тестирование Apache, PHP, MySQL под FreeBSD, Linux..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Тестирование Apache, PHP, MySQL под FreeBSD, Linux..."  
Сообщение от opennews (??) on 30-Мрт-06, 16:28 
С целью выбора операционной системы  для установки на нагруженном Web-сервере, было проведено тестирование (http://www.trinity.su/news/280.htm)  производительности работы связки Apache 1.3.34, PHP 4.4.2 и MySQL  4.1.18 на операционных системах FreeBSD 6.0 STABLE AMD64, SLES 9 SP3 AMD64 и Solaris 10 01/06 AMD64.


На тестовом сайте был установлен форум phpBB 2.0.19 и сгенерирована база из 150000  сообщений. Нагрузка генерировалась при помощи ПО Apache JMeter 2.1.1 (http://jakarta.apache.org/jmeter/index.html).


Как ни прискорбно, но несмотря на все усилия автора по оптимизации (сборка с  lpthread, включение  ULE планировщика), FreeBSD продемонстрировала значительно отставание по производительности на многопроцессорной системе.


В результате, можно отметить победу Linux при низких и средних нагрузках и подавляющее лидерство Solaris при больших.

URL: http://www.trinity.su/news/280.htm
Новость: http://www.opennet.ru/opennews/art.shtml?num=7239

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Никита (??) on 30-Мрт-06, 16:28 
Мне не понятно, почему использовалась еще сырая FreeBSD 6. Да и вообще, старнное ощущение после прочтения, автор, по-моему, не особо отличается наличием обширных знаний...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от uldus (ok) on 30-Мрт-06, 16:33 
>Мне не понятно, почему использовалась еще сырая FreeBSD 6. Да и вообще,
>старнное ощущение после прочтения, автор, по-моему, не особо отличается наличием обширных
>знаний...

Не более сырая, чем FreeBSD 5. И тюнил ее http://people.freebsd.org/~jkoshy Так что вы погорячились толком не разобравшись.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от ad (??) on 30-Мрт-06, 16:59 
А не пробовал использовать вместо libthread libthr?
Кстати вот интересная ссылка по поводу mysql на FreeBSD:
http://archive.netbsd.se/?ml=freebsd-performance&a=2005-06&t=1010016
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от uldus (ok) on 30-Мрт-06, 17:23 
>А не пробовал использовать вместо libthread libthr?

Где вы libthread увидели ? там libpthread. Не пробовал использовать вместо libthr?

http://lists.freebsd.org/pipermail/freebsd-threads/2005-January/002789.html

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от uldus (ok) on 30-Мрт-06, 17:38 
>>А не пробовал использовать вместо libthread libthr?
>
>Где вы libthread увидели ? там libpthread. Не пробовал использовать вместо libthr?

>http://lists.freebsd.org/pipermail/freebsd-threads/2005-January/002789.html

Беру свои слова обратно, там результат не время, а число запросов в секунду.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от ad (??) on 30-Мрт-06, 17:46 
>>А не пробовал использовать вместо libthread libthr?

> Где вы libthread увидели ? там libpthread. Не пробовал использовать вместо libthr?

Банальная очепятка :-)
Хотя, конечно, при том бардаке с библиотеками тридов в FreeBSD каждая буква важна.

Вопрос был к автору статьи: проводились ли измерения mysql и apache скомпилеными с libthr?
И пробовали сравнивать отдачу статики через тот же апач (возможно проблема была не только в  mysql)? Хотя, при наличии отличных результатов у Соляры и Линукса, автору наверное уже не интересно дальше с фрёй возится.

У меня в /etc/make.conf:
PTHREAD_LIBS=-lthr

.if ${.CURDIR:N*/ports/databases/mysql41-server} == ""
BATCH=yes
BUILD_OPTIMIZED=yes
WITH_CHARSET=cp1251
WITH_XCHARSET="ascii cp866 greek koi8r koi8u latin1 latin2 latin5 latin7 ucs2 utf8"
WITH_OPENSSL=yes
WITH_COLLATION=cp1251_ukrainian_ci
.endif

Замеров скорости не проводил, но работает стабильно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Аноним on 30-Мрт-06, 17:54 
>А не пробовал использовать вместо libthread libthr?
>Кстати вот интересная ссылка по поводу mysql на FreeBSD:
>http://archive.netbsd.se/?ml=freebsd-performance&a=2005-06&t=1010016

На http://www.opennet.ru/tips/info/768.shtml для 5.3 приводят такой расклад

super-smack select.key 10 1000
5250 оп/с на mysql 4.1.5/linuxthreads/FreeBSD5.3
3850 на том же, но с pthreads system scope
1090 (не опечатка) с pthreads process scope.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Аноним on 30-Мрт-06, 16:31 
все правильно - по-моему субьективному мнению - буржуи немного не ту политику избрали - гоняться -6,7, - ты сделай 5,0 да так что б комар носа не подточил -
спешка нужна при ловли блох и деверов - IMHO  все что после 4 идет - туфта - а не БЗД!!!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от universite email(ok) on 30-Мрт-06, 16:51 

>спешка нужна при ловли блох и деверов - IMHO  все что
>после 4 идет - туфта - а не БЗД!!!

6-ка очень себя неплохо показывает на продакшен серверах.
Я специально перехожу с 4.11 на 6.1.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Dyr email on 31-Мрт-06, 01:25 
Как это ни прискорбно, но я замечаю обратное. Несмотря на то, что скорость дисковой подсистемы действительно повысили, по сравнению с пятёркой, работа Apache и Proftpd вызывает серьёзные нарекания. Я так и не смог, например, в тестовых условиях заставлять отдавать их файлы на скорости выше двух с копейками Мбайт/с. Причём если ходить ЧЕРЕЗ сервер, качается всё на ура. Неоднократно встречал упоминания, что Апач у народа под шестёркой медленно работает. =(

P.S. По MySQL. Тестил встроенным sql-bench, получил такие результаты.
1. FreeBSD 5.4, MySQL 4.0.16, P4 3,0GHz, без HT:
>Totals per operation:
>Operation             seconds     usr     sys     cpu   tests
>TOTALS                3359.00  379.77  300.78  680.49 3225950

2. FreeBSD 6.0, MySQL 5.0.18, P4 3,00GHz, включен HT:
>Totals per operation:
>Operation             seconds     usr     sys     cpu   tests
>TOTALS                2867.00  292.29   89.34  381.58 3425950

3. FreeBSD 6.0, MySQL 5.0.18, AMD 64 X2 3800+ (два ядра@2,00GHz):
Лень перегружаться и смотреть, но seconds было в районе от 1500 до 1600.

Такие дела.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от smb on 31-Мрт-06, 08:21 
>Как это ни прискорбно, но я замечаю обратное. Несмотря на то, что
>скорость дисковой подсистемы действительно повысили, по сравнению с пятёркой, работа Apache
>и Proftpd вызывает серьёзные нарекания. Я так и не смог, например,
>в тестовых условиях заставлять отдавать их файлы на скорости выше двух
>с копейками Мбайт/с. Причём если ходить ЧЕРЕЗ сервер, качается всё на
>ура. Неоднократно встречал упоминания, что Апач у народа под шестёркой медленно
>работает. =(
>
>P.S. По MySQL. Тестил встроенным sql-bench, получил такие результаты.
>1. FreeBSD 5.4, MySQL 4.0.16, P4 3,0GHz, без HT:
>>Totals per operation:
>>Operation             seconds     usr     sys     cpu   tests
>>TOTALS                3359.00  379.77  300.78  680.49 3225950
>
>2. FreeBSD 6.0, MySQL 5.0.18, P4 3,00GHz, включен HT:
>>Totals per operation:
>>Operation             seconds     usr     sys     cpu   tests
>>TOTALS                2867.00  292.29   89.34  381.58 3425950
>
>3. FreeBSD 6.0, MySQL 5.0.18, AMD 64 X2 3800+ (два ядра@2,00GHz):
>Лень перегружаться и смотреть, но seconds было в районе от 1500 до
>1600.
>
>Такие дела.

Встроенный в Mysql benchmark не предназначен для реального тестирования, он однопоточный...Лучше использовать какой-нибудь sysbench, там получаются классные картины как проседает мускул при увеличении кол-ва потоков 2->4->8->16->32->64....=)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Dyr email on 31-Мрт-06, 12:35 
>Встроенный в Mysql benchmark не предназначен для реального тестирования, он однопоточный
Вот как? Я, честно говоря, не знал. В таком случае, кстати, отрыв AMD64 получается особенно впечатляющим.

>...Лучше использовать какой-нибудь sysbench, там получаются классные картины как проседает мускул при увеличении кол-ва потоков 2->4->8->16->32->64....=)
Хорошо, попробую. Может, сразу подскажете ещё, с какими параметрами его лучше запускать?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

48. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от smb on 01-Апр-06, 12:10 
/offtop:
Нашел старый кусок скрипта....вот....

sysbench --num-threads=1 --max-time=60 --test=oltp --mysql-user=<mysql_user> --mysql-db=<mysql_db> --oltp-read-only=on cleanup > cleanup
sysbench --num-threads=1 --max-time=$MT --test=oltp --mysql-user=<mysql_user> --mysql-db=<mysql_db> --oltp-read-only=on prepare > prepare
for a in "on" "off"; do
    for t in 1 2 4 8 16 32 64 128 256 512 1024; do
        echo "Now testing with --oltp-read-only=$a and --num-threads=$t"
        sysbench --max-requests=5000000 --num-threads=$t --max-time=60 --test=oltp --mysql-user=<mysql_user> --mysql-db=<mysql_db> --oltp-read-only=$a run > bench_${a}_${t}
    done;
done;
//offtop.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

43. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от ad (??) on 31-Мрт-06, 20:23 
>Как это ни прискорбно, но я замечаю обратное. Несмотря на то, что
>скорость дисковой подсистемы действительно повысили, по сравнению с пятёркой, работа Apache
>и Proftpd вызывает серьёзные нарекания. Я так и не смог, например,
>в тестовых условиях заставлять отдавать их файлы на скорости выше двух
>с копейками Мбайт/с. Причём если ходить ЧЕРЕЗ сервер, качается всё на
>ура. Неоднократно встречал упоминания, что Апач у народа под шестёркой медленно
>работает. =(

Странно, у меня что апач (2.0.55), что ftp (штатный ftpd) спокойно выдают 9.6 Mбайт/с (100 Мбитный езер). Система 6.0-STABLE от 16 января, вобщем-то вполне обычная железяка, SCSI нет,
raid'ов тоже, винт так вообще Samsung, правда SATA.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

39. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от DmA email on 31-Мрт-06, 16:59 
я думал после двойки гонка началась! :(
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Пофигист on 30-Мрт-06, 17:23 
А если б соляру на свою родную платформу...%)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Аноним on 30-Мрт-06, 17:38 
интересно, а какому количеству пользователей соответствует 1024 потока одновременно?
То есть если к практике - сколько посетителей в час надо для такой нагрузки и сколько просмотров страниц/запросов?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Аноним on 30-Мрт-06, 18:02 
А наличие этой опции ядра разве не сказывается на производительности?

makeoptions    DEBUG=-g        # Build kernel with gdb(1) debug symbols

(http://www.trinity.su/files/benchmark/bsdkernel)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от smb on 30-Мрт-06, 18:54 
Еще как сказывается...Да и вообще там ядро ни к черту....IPI_PREEMPTION и APIC куда-то дели, а еще удивляются почему не все загружено ;)
Собственно, см. ветку форума на trinity.tu....
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Sun (??) on 30-Мрт-06, 19:48 

options         IPI_PREEMPTION
device          atpic                   # Optional legacy pic support
device          mptable                 # Optional MPSPEC mptable support
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Sun (??) on 30-Мрт-06, 19:24 
не вижу там ничего типа

options         MAXSSIZ=(1024UL*1024*1024)
options         DFLDSIZ=(1024UL*1024*1024)

с несколько увеличенными показателями

также не мешало бы выложить сообщения ядра при загрузке. Итересно ведь посмотреть как это все железо видит система.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от pavel (??) on 30-Мрт-06, 19:20 
Да не , не надо на sparc, нагрузки не те. Надо просто MySQL собрать не gcc, а Сановским компилером с опциями по оптимизации памяти ( http://developers.sun.com/solaris/articles/mysql_perf_tune.html ) и посмотреть на результаты.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от smb on 30-Мрт-06, 19:48 
Какая разница чем собирать?Мы же сравниваем оси между собой, а не компиляторы...
Sun Studio нативная вещь для Solaris, и насколько я знаю только недавно был портирован под linux, а в его существовании под freebsd я вообще сомневаюсь :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от pavel (??) on 30-Мрт-06, 22:50 
Просто родной компилятор пытается использовать все известные ему преимущества ОС, вследствие этого лучше компилровать софт именно им.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от smb on 30-Мрт-06, 23:21 
Еще раз - условия тестирования должны быть _одинаковые_ для всех ОС - ибо мы идейно меряем производительность планировщика при наличии кучки процессоров, а не крутость компиляторов. Поэтому - gcc 3.4.4 =)
Другое дело, в реальной жизни естественно стоит юзать Sun Studio для сборки ПО в Solaris =)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от pavel (??) on 30-Мрт-06, 22:56 
IMHO, на сегодня Solaris 10 01/06 реальный конкурент Red Hat и Suse Linux, не говоря уж про FreeBSD, на промышленных x86 совместимых (особенно 64 bit) системах, как это не обидно сторонникам Free и прочих BSD.Да, у этих систем большая армия ФАНАТОВ, но доля их, опять таки IMHO, будет постоянно снижаться.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Michael Shigorin email on 30-Мрт-06, 23:30 
"Ну вот" (c)

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

http://www.3nity.ru/viewtopic.htm?t=6383&postdays=0&postorder=asc&start=30#38898
http://www.3nity.ru/viewtopic.htm?t=6383&postdays=0&postorder=asc&start=45

SLES с соляркой выступили как промышленные решения, что очень ярко демонстрируется и некатастрофическим влиянием тюнинга, и небольшим его объёмом до того, чтобы потащило что надо.  Фря -- где-то как тот линукс, который на всех перекрёстках поносили за то, что вокруг надо попрыгать (её тогда упоминаемой на всех перекрёстках, впрочем, и не помню).

Ещё из подумавшегося... как и намекает автор теста, фронтэнд (вроде того же nginx) был бы весьма симпатичен в качестве сдвигалки баланса нагрузки и на самом деле приближения её к тому, как (насколько знаю) и организовываются высоконагруженные динамические веб-серверы (у нас в ту же степь, но говорить о "высокой" нагрузке обычно не приходится -- слэшдоттинг как-то сдерживал скорее провайдерский шейпер в два мегабита скорее, чем остальное).

И ещё к слову для тех, кому линуксовый софт надо покрутить в руках на N процессорах -- могу запустить в vserver на 4*Xeon 550/2M.  Сейчас там 2.4 и, соответственно, без NPTL.

Ergo: удачи нам всем находить нужный софт под свои задачи и нужные задачи под свой софт!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

34. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от grobik on 31-Мрт-06, 14:32 
Жаль, что при тестировании производительности MySQL на FreeBSD не использовались рекомендации отсюда: http://wikitest.freebsd.org/moin.cgi/MySQL
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "what if..."  
Сообщение от Michael Shigorin email on 31-Мрт-06, 17:36 
>Жаль, что при тестировании производительности MySQL на FreeBSD не использовались рекомендации отсюда:
>http://wikitest.freebsd.org/moin.cgi/MySQL
Нескромный вопрос -- как думаете, если линукс заточить при участии kernel developers с теми же времязатратами, что получится?  А если mysql и прочее на нём ещё потюнить даже без пересборок?  А если поверх ещё nginx набросить?..

Веб-сервер в нашем веке обычно не является подкованной блохой всё-таки.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

42. "what if..."  
Сообщение от ad (??) on 31-Мрт-06, 20:16 
Если линукс заточить при участии kernel developers то получится ровно тоже, что и сейчас, потому что девелоперы MySQL плотно взаимодействуют с kernel developers Linux'а.
Тут вопрос в другом, FreeBSD поставляется с незаточеной конфигурацией :-( Это есть крупный (очень крупный) недостаток, приходится администратору делать то, что уже за него сделали в RedHat или Novell, если бы он использовал Линукс.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

44. "так mysql ни при чём особенно?"  
Сообщение от Michael Shigorin email on 31-Мрт-06, 20:52 
>Если линукс заточить при участии kernel developers то получится ровно тоже, что
>и сейчас, потому что девелоперы MySQL

А при чём тут девелоперы MySQL? (вопрос "почему" взаимодействуют -- гуманизму ради оставим за кадром)

Там ведь не mysqld создавал нагрузку.  Кстати, по этой же причине все постинги что здесь, что на 3nity.ru по части игрищ в тредовые библиотеки точно так же малорелевантны.

(кстати... есть тут знакомые mysql developers, и непростые промышленные пользователи фри с ним на борту -- тоже.  какие суровые будни им выдавались при попытках с год тому жить с KSE и новыми тредами на SMP -- опять же оставим)

>Тут вопрос в другом, FreeBSD поставляется с незаточеной конфигурацией :-(

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

Плюс не знаю как кого, а меня "Untuned FreeBSD" с пометкой "только ядро пересобрали" всплакнуло.  Видать, давно не собирал линуксовых ядер, поскольку умнее Sergey Vlasov себя не считаю, да и архитектура более чем практична для того, чтобы это не было необходимо.

>Ребята, проводившие тестирование, не слишком разбираются в аспектах системы,
>иначе результаты получились бы несколько другими.

Во фре бы сразу весь испарился GKL и автомагически была проведена та работа по тонкому локингу, которая годами (!) выполнялась для линуксового ядра вслед за солярисным?  Что-то не верится.

(если кто недочитал тамошнее обсуждение, то опубликованный фрёвый конфиг был снят с последней стадии системы, когда jkoshy@ уже её раскладывал по столу; потому и отладка)

>Думаю, все же проблема была далеко не в mysql, которому уделили такую кучу внимания.

Вот и мне так кажется.

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

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

Делайте выводы, народ.

PS: упоминание красноглазых выше в первейшую очередь относится к деятелям, которые отметились на http://www.3nity.ru/viewtopic.htm?t=6383&postdays=0&postorder=asc&start=45 как "FromOn" и "SysR".  Причём первый больше похож на новичка с картинами чьих-то распальцовок в глазах, а вот второй -- клинический больной, который уже больше верит своим галлюцинациям и в свою круть, чем фактам.  Гордыня.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

45. "так mysql ни при чём особенно?"  
Сообщение от terver on 31-Мрт-06, 21:14 
> если кто недочитал тамошнее обсуждение, то опубликованный фрёвый конфиг был снят с последней стадии системы, когда jkoshy@ уже её раскладывал по столу

Разъясните, пожалуйста, что значит "раскладывал её по столу"? Вы имеете ввиду, что Koshy занимался дебагингом? Из Индии?

> Судя по тому, что народ поступил грамотнее и пнул разработчиков

Плохо пинал видимо, про такие вещи как IPI_PREEMPTION они бы вряд ли забыли :-( Пнули бы Роберта Ватсона, что ли :-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

35. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от zuborg on 31-Мрт-06, 14:36 
StartServers 200
MaxClients 150
отличная шутка, интересно как соляра сумела удержать низким время отклика при таких условиях ))
модули через mod_so лоадятся, это на продашн то сервере, мдя
mod_autoindex там очень кстати, наверное, как и куча других модулей
нету AcceptFilter On, ну это так, к слову
/etc/sysctl.conf надо полагать вообще не трогал никто, по крайней мере упоминания об этом я не нашел. А ведь фря по умолчанию оптимизирована как веб-клиент, а не веб-сервер.

в my.cnf нет query_cache_type= 1 , а зря

в общем, действительно комментариев по FreeBSD нет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

36. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Vanoha on 31-Мрт-06, 14:49 
Если внимательно посмотреть на результаты, то можно увидеть, что более 256 потоков - это эммуляция заведомо нерабочей ситуации.
Т.е. все результаты с большим количеством потоков можно не рассматривать.

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

Поэтому выводs по тестам несколько другие:
1. В разумной конфигурации BSD не выдерживает никакой конкуренции с linux и Solaris.
2. При низкой нагрузке Linux ведет себя лучше остальных.
3. Более 256 потоков при любой ОС - плохая конфигурация (т.е. выходящая за рамки нормального рабочего режима).
4. За границей рабочего режима Solaris ведет себя устойчиво.

Кстати, Solaris подтвердил давно известные факты:
1. Малые накладные расходы при переключении между процессами
2. Умение хорошо работать при разных перегрузках (к слову - этим же славятся AIX и VMS)

Вообще, тест конечно слегка "натянутый", но тем не менее хотелось бы увидеть нечто похожее не на "форкающемся" Apache 1.3, а на 2.0, который нормально поддерживает threads.

Кстати, использованные тесты обычно применяются для определения границ работоспособности и оптимизации параметров систем.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

37. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Аноним on 31-Мрт-06, 15:12 
кто мне скажет, это какого уровня проэкт должен быть, чтобы 256 потоков обслуживать?
Скольно народу в час/просмотров страниц?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

38. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от zuborg on 31-Мрт-06, 15:41 
несколько сотен тысяч посетителей в день
одна машина выдерживает от 100K до 1000K посетителей,
но это сильно зависит как от оптимизированности проекта,
так и от качества драйверов железа.

ЗЫ: иногда не хватает и MaxClients 1024, но это нечасто.
Причем никакой особенной деградации производительности.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

49. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от zyxman on 08-Апр-06, 06:53 
>несколько сотен тысяч посетителей в день
>одна машина выдерживает от 100K до 1000K посетителей,
>но это сильно зависит как от оптимизированности проекта,
>так и от качества драйверов железа.
>
>ЗЫ: иногда не хватает и MaxClients 1024, но это нечасто.
>Причем никакой особенной деградации производительности.

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

у меня был опыт борьбы с одним таким, который сделал форум с хранением данных в mysql, при этом даже не понимая, как индексы создать - как только количество сообщений в базе превысило 10к, больше 30 человек в форуме не могло нормально присутствовать, а однажды зашли 50 и пришлось лавочку совсем закрыть..
Кстати, все это крутилось на слаквари, mysql 3.x, apache 1.3.x..

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

Просто большое количество открытых сокетов не опасно - сам работал с системой, где один прокси на фре 2.х на сквиде (без каки-то нестандартных настроек, кроме maxusers=32 в ядре) обслуживал несколько тысяч клиентов и было в нормальном состоянии открыто около 600 соединений - поэтому почти всегда есть смысл ставить реверсивный прокси.

Кстати, поищите, где-то в форумах рассказывали на чем рамблер жил несколько лет назад (всего один p2-450/512RAM) - просто тщательно настроен апач + аккуратно написаны скрипты + статику отдавали чем-то сверхлегким.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

41. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от uldus (ok) on 31-Мрт-06, 17:53 
>кто мне скажет, это какого уровня проэкт должен быть, чтобы 256 потоков
>обслуживать?

Любой проект может с этим столкнуться, если ссылка на него появится в slashdot или хотябы на news.yandex/rambler.ru :-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

46. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от terver on 31-Мрт-06, 21:17 
интересно под чем работает сам слэшдот :-)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

47. "Тестирование Apache, PHP, MySQL под FreeBSD, Linux и Solaris..."  
Сообщение от Аноним on 01-Апр-06, 01:18 
http://slashdot.org/faq/tech.shtml
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

50. "OpenNews: Тестирование Apache, PHP, MySQL под FreeBSD, Linux..."  
Сообщение от def email(??) on 31-Май-06, 20:11 
Использую FreeBSD больше 5 лет. Постоянно занят оптимизацией связки mysql/apache/php. Толька большая любовь к FreeBSD и уважение к команде разработчиков держит.

Ловите мои тесты, делал 3 месяца назад, mysql 4.1.16 тогда была. Юзаю два года LINUXTHREADS. На больших нагрузках бывают сбои, система сейчас SMP (Intel).

root@shelter# uname -a
FreeBSD shelter 6.0-RELEASE-p3 FreeBSD 6.0-RELEASE-p3


make WITH_CHARSET=cp1251 WITH_XCHARSET=all WITH_PROC_SCOPE_PTH=yes BUILD_OPTIMIZED=yes BUILD_STATIC=yes WITHOUT_INNODB=yes

root@shelter# super-smack select-key.smack 10 1000
Query Barrel Report for client smacker1
connect: max=4ms min=1ms avg= 3ms from 10 clients
Query_type num_queries max_time min_time q_per_s
select_index 20000 3 0 5953.17


root@shelter# for i in 1 2 3 4 5; do super-smack select-key.smack 10 1000 | grep select_index; done
select_index 20000 3 0 5970.28
select_index 20000 1 0 6033.27
select_index 20000 2 0 5987.75
select_index 20000 1 0 5950.09
select_index 20000 1 0 6456.59


root@shelter# for i in 1 2 3 4 5; do super-smack update-select.smack 10 1000 | grep select_index; done
select_index 10000 1 0 2850.87
select_index 10000 2 0 2876.46
select_index 10000 2 0 2900.69
select_index 10000 1 0 2949.64
select_index 10000 1 0 2768.93

root@shelter# super-smack select-key.smack 10 10000
Query Barrel Report for client smacker1
connect: max=3ms min=2ms avg= 2ms from 10 clients
Query_type num_queries max_time min_time q_per_s
select_index 200000 1 0 6024.51

----------------------------------------------------------------
WITH_CHARSET=cp1251 WITH_XCHARSET=all WITH_LINUXTHREADS=yes WITH_PROC_SCOPE_PTH=yes BUILD_OPTIMIZED=yes BUILD_STATIC=yes WITHOUT_INNODB=yes

root@shelter# super-smack select-key.smack 10 1000
Query Barrel Report for client smacker1
connect: max=3ms min=1ms avg= 2ms from 10 clients
Query_type num_queries max_time min_time q_per_s
select_index 20000 0 0 12726.61

root@shelter# for i in 1 2 3 4 5; do super-smack select-key.smack 10 1000 | grep select_index; done
select_index 20000 0 0 12972.70
select_index 20000 1 0 13186.32
select_index 20000 0 0 12805.09
select_index 20000 0 0 12842.54
select_index 20000 0 0 13197.56

root@shelter# for i in 1 2 3 4 5; do super-smack update-select.smack 10 1000 | grep select_index; done
select_index 10000 2 0 4903.96
select_index 10000 1 0 4720.51
select_index 10000 1 0 4974.32
select_index 10000 2 0 4949.03
select_index 10000 1 0 4955.58

root@shelter# super-smack select-key.smack 10 10000
Query Barrel Report for client smacker1
connect: max=3ms min=1ms avg= 1ms from 10 clients
Query_type num_queries max_time min_time q_per_s
select_index 200000 0 0 12827.56

----------------------------------------------------------------
WITH_CHARSET=cp1251 WITH_XCHARSET=all WITH_LINUXTHREADS=yes BUILD_OPTIMIZED=yes BUILD_STATIC=yes WITHOUT_INNODB=yes

root@shelter# super-smack select-key.smack 10 1000
Query Barrel Report for client smacker1
connect: max=5ms min=2ms avg= 2ms from 10 clients
Query_type num_queries max_time min_time q_per_s
select_index 20000 0 0 12815.30

root@shelter# for i in 1 2 3 4 5; do super-smack select-key.smack 10 1000 | grep select_index; done
select_index 20000 0 0 12839.03
select_index 20000 1 0 12893.93
select_index 20000 1 0 12768.72
select_index 20000 0 0 12750.90
select_index 20000 0 0 12840.02

root@shelter# for i in 1 2 3 4 5; do super-smack update-select.smack 10 1000 | grep select_index; done
select_index 10000 1 0 4933.73
select_index 10000 1 0 4955.65
select_index 10000 1 0 4945.07
select_index 10000 1 0 4960.90
select_index 10000 1 0 4939.61


root@shelter# super-smack select-key.smack 10 10000
Query Barrel Report for client smacker1
connect: max=3ms min=1ms avg= 1ms from 10 clients
Query_type num_queries max_time min_time q_per_s
select_index 200000 0 0 12908.48

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

51. "OpenNews: Тестирование Apache, PHP, MySQL под FreeBSD, Linux..."  
Сообщение от weldpua2008 email(ok) on 22-Окт-06, 14:36 
>Использую FreeBSD больше 5 лет. Постоянно занят оптимизацией связки mysql/apache/php. Толька большая
>любовь к FreeBSD и уважение к команде разработчиков держит.
>
>Ловите мои тесты, делал 3 месяца назад, mysql 4.1.16 тогда была. Юзаю
>два года LINUXTHREADS. На больших нагрузках бывают сбои, система сейчас SMP
>(Intel).
у Меня вопрос - а что эти тесты показывают?
(только не пинать)
И как они позиционируют Себя в сравнени с тестами у топикстартера?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]


  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor