Нет, не обманываете, а прикидываетесь что не понимаете о чем речь:
кто-то верит, что существуют приложения без пост обработки данных после получения их с базы данных? Добавить немного логики в вычисления, и красивые цифры в пользу php разрушаться
Поэтому ваш код брать даже смысла нет, потому что он ничего не делает
Но если вы настаиваете, что такие бывают, то всё еще проще, для таких приложений уровня как вы тестируете совершенно не важно что брать, потому что там не будет больше 2х человек в месяц
С этим «тестом» та же история, только новичков пугать, не зря минусуют. Или кто-то верит, что существуют приложения без пост обработки данных после получения их с базы данных? Добавить немного логики в вычисления, и красивые цифры в пользу php разрушаться
В общем — ситуацию надо было спасать. Засучив рукава, мы начали с чистого листа искать решение.
Молодцы, что решение всё таки нашли. Но так как статья с меткой «tutorial», то стоит отметить, что в mysql для таких целей уже есть всё необходимое (youlose уже упоминал это). Достаточно добавить в my.cnf несколько строчек:
В файл /var/log/mysql/slow.log будут попадать запросы которые выполняются медленнее 1 секунды, а так же запросы которые не используют индексы. Кроме самих запросов там много сопутствующей информации. В mariaDB или percona информации даже больше будет
test1
В js по сути тоже самое, вместо resultStr += newStr при большом кол-ве объединений строк лучше использовать
arr.push(newStr);
resultStr = arr.join('');
Это и памяти израсходует намного меньше и выполнится быстрее
Результаты вашего теста на той же машине, что и php и js (если вам интересно):
test1 (StringBuilder): 46 ms
str len: 1000000 sb
test2 (sum): 16 ms
sum: 2500000
test3 (Stack): 42 ms
stack len: 1000000 z
test3 (Array): 17 ms
array len: 1000000 z
test4 (array fill): 15 ms
obj1: b
obj2: a
test Map (hashmap-Integer): 143 ms
obj1: b
obj2: a
test Map (hashmap-String): 394 ms
obj1: b
obj2: a
То что java выигрывает по скорости вполне ожидаемо
То что вы упорно твердите про отключение оптимизатора (хотя даже намека на это нет, и если бы вы разбирались или если были бы внимательнее, то уже поняли бы это), говорит о том, что вы совершенно не понимаете о чем говорите, но при этом оскорбляете других
Тогда странно, что вы умудряетесь говорить очевидные глупости вроде:
«Скажите мне, с какого бодуна вы решили, что для сравнения производительности необходимо кастрировать php и nodejs убрав влияние их оптимизаторов?»
Впрочем фраза «вы дурочки оба» хорошо вас характеризует
Да, внезапно. Внезапно стало понятно, что вы видео не смотрели, не понимаете как работают оптимизаторы, вы не поняли о чем статья и к чему были правки, но так как вам скучно, вы захотели тянуть кота за хвост и выдумали себе тему для беседы
Логика в том, что бенчмарки производительности не подразумевают сравнение пустого по смыслу цикла (оптимизатор выкинул всё из него, потому что результат не фиксируется дальше по программе, или заинлайнил весь цикл, потому что понял что ничего особенного в цикле не происходит). Так работают оптимизаторы, именно об этом рассказывается в видео
Но в статье анонсировано сравнение производительности, а не сравнение чем оптимизатор лучше детектит бессмысленные циклы. Поэтому в эти циклы нужно добавить немного «логики» и считывать результат выполнения в этих циклах. Вот это и называется логика
Но если вы продолжаете настаивать, что автор хотел именно сравнить пустые по смыслу циклы, то опять же, обсуждать тут нечего
Нет, не будем формальны, будем логичны
Начало статьи
Всем привет, решил поделиться с вами результатами синтетического теста производительности свежих версий PHP и Node.js.
Эти синтетические тесты сделаны с ошибкой, в видео рассказывается причина таких ошибкой. На ошибки указано, новые результаты приведены. Особо больше тут нечего обсуждать
Я лишь добавила в его сценарий необходимый минимум, чтобы тестирование было объективным. А так же указала, что доступ к mysql сделан с ошибкой, и сравнение веб-серверов сделано не правильно
То что подобное сравнение совершенно бессмысленно, этот вопрос уже в другой ветке обсуждался
Эта ссылка уже приводилась, речь не про нее. Речь про то, что те кто хотят сравнить свои сценарии использования, должны учитывать некоторое особенности работы оптимизаторов и по ссылке видео где рассказывается как правильно сравнить (там пример для js, но общий смысл для всех систем один)
Но что-то он точно умеет делать (по крайней мере opcache точно умеет, который на сколько я знаю с php7 какой-то версии включен по умолчанию)
Иначе добавление небольшой логики и чтение результата не могло бы привнести такую разницу:
Пример из статьи
node test1: 49ms
php test1: 13ms
//php как будто-бы разгромно выигрывает
Пример из статьи + "логика":
node test1: 67ms
php test1: 83ms
//php уже отстает, хотя сложности вычислений почти не добавилось
Оффтоп:
Тоже самое со всеми остальными тестами (где игнорируется совет мелкие строки всегда не складывать, а пушить в массив и потом джойнить, вместо чтения ответа с mysql читается ошибка соединения, вместо 1xphp-fpm vs 1xnode тестируется 5xphp-fpm vs 1xnode и т. д.)
Сравнивают всё равно не php-fpm vs node, а нерабочий вариант vs нерабочий вариант и даётся это под видом каких-то выводов
Не вижу в статье добавление чтения результата. Так же нужно хотя бы примитивную логику добавлять в любые микробенчмарки
Вот правильное тестирование (ваш тест только добавлена логика и чтение результата) и результат не в пользу php: https://habrahabr.ru/post/320670/#comment_10039552
Поэтому ваш код брать даже смысла нет, потому что он ничего не делает
Но если вы настаиваете, что такие бывают, то всё еще проще, для таких приложений уровня как вы тестируете совершенно не важно что брать, потому что там не будет больше 2х человек в месяц
https://habrahabr.ru/post/323208/#comment_10101554
То есть php не «в разы быстрее», а медленнее
С этим «тестом» та же история, только новичков пугать, не зря минусуют. Или кто-то верит, что существуют приложения без пост обработки данных после получения их с базы данных? Добавить немного логики в вычисления, и красивые цифры в пользу php разрушаться
В файл /var/log/mysql/slow.log будут попадать запросы которые выполняются медленнее 1 секунды, а так же запросы которые не используют индексы. Кроме самих запросов там много сопутствующей информации. В mariaDB или percona информации даже больше будет
В js по сути тоже самое, вместо resultStr += newStr при большом кол-ве объединений строк лучше использовать
Это и памяти израсходует намного меньше и выполнится быстрее
Результаты вашего теста на той же машине, что и php и js (если вам интересно):
То что java выигрывает по скорости вполне ожидаемо
«Скажите мне, с какого бодуна вы решили, что для сравнения производительности необходимо кастрировать php и nodejs убрав влияние их оптимизаторов?»
Впрочем фраза «вы дурочки оба» хорошо вас характеризует
Но в статье анонсировано сравнение производительности, а не сравнение чем оптимизатор лучше детектит бессмысленные циклы. Поэтому в эти циклы нужно добавить немного «логики» и считывать результат выполнения в этих циклах. Вот это и называется логика
Но если вы продолжаете настаивать, что автор хотел именно сравнить пустые по смыслу циклы, то опять же, обсуждать тут нечего
Начало статьи
Эти синтетические тесты сделаны с ошибкой, в видео рассказывается причина таких ошибкой. На ошибки указано, новые результаты приведены. Особо больше тут нечего обсуждать
То что подобное сравнение совершенно бессмысленно, этот вопрос уже в другой ветке обсуждался
https://www.youtube.com/watch?v=HPFARivHJRY
1 треад:
php-fpm: 1612 req/sec
node.js: 3854 req/sec
5 тредов:
nginx+php-fpm: 5373 req/sec
nginx+node.js: 9845 req/sec
Не знаю уж как вы тестировали
Иначе добавление небольшой логики и чтение результата не могло бы привнести такую разницу:
Оффтоп:
Тоже самое со всеми остальными тестами (где игнорируется совет мелкие строки всегда не складывать, а пушить в массив и потом джойнить, вместо чтения ответа с mysql читается ошибка соединения, вместо 1xphp-fpm vs 1xnode тестируется 5xphp-fpm vs 1xnode и т. д.)
Сравнивают всё равно не php-fpm vs node, а нерабочий вариант vs нерабочий вариант и даётся это под видом каких-то выводов
Вот правильное тестирование (ваш тест только добавлена логика и чтение результата) и результат не в пользу php:
https://habrahabr.ru/post/320670/#comment_10039552