PHP Geschwindigkeit Windows vs Linux

[MaxDau]

Hallo
Ich hoffe, dass das hier richtig ist.
Ich habe 2 gleiche VMs auf einem Host gestartet. 8GB Ram und 16 Kerne.
Auf beiden ist PHP 8.1 NTS installiert.
Starte ich nun eine einfache PHP - Hash Berechnung liegt ein sehr extremer Unterschied zwischen Windows und Linux.
Durchschnittliche Ausführung bei 100 Durchläufen:
Windows: 0.2088 Sekunden
Debian: 0.5863 Sekunden

Wie beschrieben, die Hardware ist absolut identisch. Ich kann mir nicht erklären, warum Debian 3 mal langsamer ist.
Hat jemand eine Idee?

 

[GwenDragon]

Welches Windows genau?
Welches Debian genau?
Welche PHP-Version?
Wie sieht der PHP-Code aus?
Würd ich gern in Virtualbox 6 VM testen.

 

[GwenDragon]

Debian 11? Die hatten Änderungen bei /dev/random und dem Kernel, vielleicht deswegen.

 

[MaxDau]

Die nächtlichen Stunden haben es gestern offenbart. Es lag an der random_bytes Funktion von PHP. Warum genau, habe ich bisher nicht herausgefunden und habe auch keine Idee mehr. Entropie war genug vorhanden und stieg während der Ausführung weiter.

uname -a
Linux xxx 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux

php -v
PHP 8.1.8 (cli) (built: Jul 11 2022 08:55:24) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.8, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.8, Copyright (c), by Zend Technologies

Mit der Config aus dem Anhang habe ich folgende Ausführungszeiten:
doJob2 (random_bytes() + hash()):
Windows: 3,04 Sek.
Debian: 103,11 Sek.

doJob (hash() + String):
Windows: 55,66 Sek.
Debian: 42,02 Sek.

Während der Ausführung zeigt mir

cat /proc/sys/kernel/random/entropy_avail

immer über 3.000 an.
In der proc.php kannst du ein paar Einstellungen zu den Jobs, parallelen Prozessen und dem Befehlt vornehmen und in der runJob.php zwischen doJob (hash + String) oder doJob2(random_bytes + hash) wechseln.
Ausführung nur als CLI getestet.
Max. parallele Prozesse über die Anzahl der Threads zu setzen sollte nichts bringen, da alle Prozesse keinen I/O-Delay haben, sondern reine Rechenleistung benötigen und damit die Threads schon am Limit sind.
Ich habe das Script es zum Spass mal mit DNS Abfragen beschäftigt. Da hatte ich bei 32 Kernen und 300 Prozessen eine gute Auslastung. Man muss da mit dem usleep ein bisschen testen, was die besten Werte sind um möglichst wenig Leerläufe zu haben, was unnötige Last erzeugt.