The default limits of MacOS is not really web server benchmark friendly. ulimit -a Maximum size of core files created (kB, -c

The default limits of MacOS is not really web server benchmark friendly. ulimit -a Maximum size of core files created (kB, -c) 0 Maximum size of a process’s data segment (kB, -d) unlimited Maximum size of files created by the shell (kB, -f) unlimited Maximum size that may be locked into memory (kB, -l) unlimited Maximum resident set size (kB, -m) unlimited Maximum number of open file descriptors (-n) 256 Maximum stack size (kB, -s) 8176 Maximum amount of CPU time in seconds (seconds, -t) unlimited Maximum number of processes available to current user (-u) 5333 Maximum amount of virtual memory available to each process (kB, -v) unlimited Debian's limits are better: ~> ulimit -a Maximum size of core files created (kB, -c) 0 Maximum size of a process’s data segment (kB, -d) unlimited Control of maximum nice priority (-e) 0 Maximum size of files created by the shell (kB, -f) unlimited Maximum number of pending signals (-i) 30744 Maximum size that may be locked into memory (kB, -l) 993336 Maximum resident set size (kB, -m) unlimited Maximum number of open file descriptors (-n) 64000 Maximum bytes in POSIX message queues (kB, -q) 800 Maximum realtime scheduling priority (-r) 0 Maximum stack size (kB, -s) 8192 Maximum amount of CPU time in seconds (seconds, -t) unlimited Maximum number of processes available to current user (-u) 30744 Maximum amount of virtual memory available to each process (kB, -v) unlimited Maximum contiguous realtime CPU time (-y) unlimited For testing I always create an instance somewhere (mostly AWS) and configure the OS to have much higher performance limits to enable better performance outcomes.