ну это лишь говорит о том что v3 2.4ггц ядро в нашем тесте действительно выдает результат не хуже 3.4-3.5ггц ядер, но на 2 поколения старше.
но того же v3 поколения и выше частотой все-таки ведь по-быстрее.
все логично и адекватно
конечно, бесспорно, очень влияют настройки, количество модулей php и много чего еще.
но опять же, конечным пользователям что с того? им ведь конечный результат и нужен.
у меня так получается:
этим скриптом
<?php // Инициализация тестирования циклов $start = microtime(true); for($c = 30000000; $c >= 0; $c--); while($c < 30000000) ++$c; // Считаем время выполнения циклов $time = round(microtime(true) - $start, 3); echo $time." мс".PHP_EOL; echo round(30000000 / $time)." операций\n\n"; ?>
любопытно.
попробовал у себя, и действительно, на php5.6 "циклы" не больше 28 получается
а на php5.5 и 5.4 выдает по 35-36
значит в конкретно тех задачах что скрипт там делает, 5.4 и 5.5 по-быстрей получаются, чем 5.6
но 7.0 все равно круче, там больше 80 бывает.
5.4 - https://tools.lite.company/performance/bc09b50a-0c8b-11e7-8287-001a42d5d624
5.5 - https://tools.lite.company/performance/7b263019-0c8b-11e7-8287-001a42d5d624
5.6 - https://tools.lite.company/performance/936e38c9-0c89-11e7-8287-001a42d5d624
7.0 - https://tools.lite.company/performance/2883692c-0c8b-11e7-8287-001a42d5d624
а 400 итоговых кто-нибудь перешагнул интересно? :)
и php -v еще вдобавок покажите.
если там php7, то не удивительно что он их сделал.
но даже если 5.6, то он ведь v3, а те v1. все может быть.
не надо все так близко на свой счет принимать. никого конкретно не имел в виду.
и возмущаться результатам также не стоит.
скрипт делает определенный набор вычислений и разные процессоры с разной скоростью их выполняют. что есть, то есть. все претензии производителю :)
пробежался по теме и так понял суть:
человек сделал скрипт для оценки производительности php здесь и сейчас.
без оглядки на количество ядер, mysql, загруженность...
просто чтобы узнать на сколько быстр php прямо сейчас на каком-нибудь хосте.
можно его порефрешить и увидеть прилично отличающиеся цифры, но более-менее оценить производительность можно.
в чем проблема?
отличная штука.
а хостеры, наверное у которых маленькие цифры написало, зафукали 🙄
вам уже 10 раз сказали - да, скрипт измеряет только php одним процессом, все точка.
зачем сюда приплетать mysql, возмущаться одинаковым цифрам на 4 и 100 ядрерных системах?
все правильно, конечным пользователям надо скорость их собственного php скрипта.
какую нагрузку выдержит сервер, сколько еще таких пользователей он параллельно тянет, как там cloudlinux режет cpu - юзерам глубоко до лампочки. их интересует лишь как быстро выполнится их скрипт.
никто ж не спорит, что в итоге если добавить mysql, добавить количество посетителей, то сайт может будет работать лучше на хосте, который показал меньше попугаев в этом тесте.
это совершенно другой вопрос. который больше касается вопроса оверселлинга хостером.
плюс так понимаю нигде открытой статистики итоговой нет.
никто никого позорить не собирается. чего возмутились-то?
да причем тут материнка если диски-то разные.
у ssd все очень сложно с производительностью. упор на разные вещи делается, разные настройки изначально ставятся и по-разному можно самостоятельно настроить.
есть к примеру micron p320h 700gb, вроде бы замечательная вещь, SLC, 50Pb ресурс, 3.2/1.9 скорости чтения/записи. вот только создавалась она изначально под многопроцессорные системы с расчетом на то что ее грузить будут одновременно большим количеством потоков задач. ей подавай блоки данных по-больше и глубину очереди в 256 хотя бы.
при этом у нее есть настройка чтобы сместить производительность в сторону маленькой очереди, хоть и в ущерб максимальным iops'ам.
так вот даже при такой настройке она при обычной небольшой нагрузке маленькой очередью с маленькими блоками показывает хуже производительность чем p3700 400gb на MLC с 2.7/1.0 скоростями (и в раз в 7 ниже ресурсом, к слову).
запись 4k блоками, очередь 8 - 320мб/с
а если подбавить размер блока до 64k и глубину увеличить до 256 уже получаем положенные 1.9гб/с на запись
в то время как p3700 при тех же 4k/8 уже с ходу выдает больше 800мб/с запись:
т.е. p3700 больше подходит для однопроцессорного не слишком загруженного серверка.
хоть p320h в целом гораздо круче, но она просто не раскроет себя полностью в обычных задачах.
но зато можно пользоваться и вообще не переживать за надежность. 50 петабайт - это уровень!
сколько там ресурс на ваших самсунгах? 🙄
а вот для сравнения они же в смешанном тесте read/write 4k/64
т.е. более-менее на равне ~580 чтение и 190 запись
но опять же, если куда-нибудь сместить размер блока или глубину очереди, то кто-то из них будет вырываться в лидеры.
ну и для сравнения sata'шный s3700 400:
145/48 мб/с "всего лишь". в кавычках т.к. все равно в том же битриксе как видите вполне вменяемый результат выдает.
что покажут pci-e диски, поглядим... хотя там же не только от дисков все зависит.
в общем мораль такова - если вам кажется что "pro" самсунг проигрывает в производительности, то возможно он еще проявит себя в чем-то другом. например дольше проживет :)
ну и стоит поковырять фирменными утилитами разные настройки. я правда не знаю что там как у самсунгов, но наверняка что-то должно быть.
к примеру в p320h по-умолчанию write buffer был выключен и от этого производительность была еще хуже.
я его включил и по-лучше стало, правда пугает вариант с пропадением питания и потерей данных из буфера.
на более современных s3700/p3700/p420m для этого есть встроенный конденсатор, который в случае чего поддержит питание и закончит запись нормально.
диски? :)
1шт там трудится.
материнка x10sll-f
качал отсюда:
http://www.1c-bitrix.ru/download/cms.php#tab-php-link
Эксперт 16.5.4 - suffix за эксперт вроде выше писал, ее и поставил.
besthosting в Виннице. откуда инфа про Киев?
да здесь выложите.
я сегодня решил погуглить что за битрикс такой, скачал такую-то демо версию, поставил, потестил тоже ради спортивного интереса 🙄
на серверке с 300+ работающими сайтами, который загружен все время процессором на 30-40% получилось такое:
так полагаю от настроек здесь ОЧЕНЬ многое зависит.
к примеру при установке mysql myisam или innodb был выбран?
я оставил что по-умолчанию предлагалось - myisam.
ничего больше не трогал, все по-умолчанию.
nginx+apache2.4 / php 7.1.2 (как модуль) / e3-1270v3 / s3700 400Gb / 32Gb ram
155 попугаев пишет.
тест диска с первой страницы здесь вот такой результат дал:
плюс из-за того что сервер не пустой стоит, результаты очень прилично пляшут от теста к тесту.
если никакой другой нагрузки нет, то конечно цифры будут максимальные.
хотя смотрю сюда допустим: https://aspro.ru/company/news/1234/
сверяю со скрином где 200 результат и все цифры под ним у меня вроде бы по-лучше.
как же тогда эта общая цифра высчитывается не пойму 😕
показывайте еще кто-нибудь скрины со всеми результатми (процессор, файловая система и т.д.) и подробностями на чем тестировалось и как оно параллельно было загружено.
я позже донастраиваю еще другой серверок с еще по-круче процем и ssd, посмотрю что там напишет за результат
а еще там же пишут https://wiki.archlinux.org/index.php/Solid_State_Drives_%28%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%29
"иногда на некоторых SSD это может приводить к замедлению работы при удалении файлов".
вместо discard лучше по cron запускать fstrim ночью.
но я в целом про то что не надо особо ориентироваться на результаты в FOB состоянии (по этой терминологии), а ближе к реальной жизни результаты в Steady State.
ведь диск может быть к примеру под крышку забит данными и что тогда trim подчищать должен по-вашему? а писать/перезаписывать допустим надо. тут и окажется что скорость будет далеко не Fresh-Out-of-Box
еще можно такие тесты провести попробовать:
aptitude install fio
случайное чтение:
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread
случайная запись:
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
случайное чтение/запись:
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
при bs=4k конечно же скоростя будут не такими радужными как при 64k, но правда ли в реальности оно у вас будет писать большими блоками?
