Hi!
I've recently succeeded in running SugarCRM (if you don't know what it
is, it is a big app, lots of code, lots of memory used, lots of db
queries, etc.) on phpng and did some benchmarks, and I was asked to
share the results with everybody. So here it goes:
Benchmark setup:
- lighttpd with fcgi driver
- Single process PHP: sapi/cgi/php-cgi -b 9999
- ab as benchmark driver, like: ab -k -c 1 -n 100 -C
'PHPSESSID=223876233264873232523'
'http://127.0.0.1:8080/sugar674u/index.php?module=Accounts&action=index&ajax_load=1' - SugarCRM 6.7.4
- opcache and php config as described in wiki here:
https://wiki.php.net/phpng
Benchmark 1:
DetailView on Sugar. This view has a lot of data and SQL queries. Results:
MASTER:
Total transferred: 21022400 bytes
HTML transferred: 20957000 bytes
Requests per second: 3.51 [#/sec] (mean)
Time per request: 284.997 [ms] (mean)
Transfer rate: 720.32 [Kbytes/sec] received
PHPNG:
Total transferred: 21022400 bytes
HTML transferred: 20957000 bytes
Requests per second: 4.70 [#/sec] (mean)
Time per request: 212.929 [ms] (mean)
Transfer rate: 964.12 [Kbytes/sec] received
Benchmark 2:
ListView on Sugar. This view is smaller since it has only one data set
(list of records)
Results:
MASTER:
Total transferred: 12386000 bytes
HTML transferred: 12320600 bytes
Requests per second: 8.64 [#/sec] (mean)
Time per request: 115.692 [ms] (mean)
Transfer rate: 1045.45 [Kbytes/sec] received
PHPNG:
Total transferred: 12386000 bytes
HTML transferred: 12320600 bytes
Requests per second: 12.03 [#/sec] (mean)
Time per request: 83.153 [ms] (mean)
Transfer rate: 1454.55 [Kbytes/sec] received
So, we have 25-30% improvement, which definitely sounds very good. Of
course, these benchmarks are single-thread no-load benchmarks on single
Will also look a bit later into seeing how it behaves memory-wise (it
uses a lot of memory usually so may be interesting to see what happens
there) and how latest version (which has shorter and leaner requests)
behaves.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I've recently succeeded in running SugarCRM (if you don't know what it
is, it is a big app, lots of code, lots of memory used, lots of db
queries, etc.) on phpng and did some benchmarks, and I was asked to
share the results with everybody. So here it goes:
-snip-
Nice real world results! Thanks for sharing Stas.
It’d be great if others could also give phpng a quick try with their apps and share results. That’ll help give us a bit more visibility into the current impact for various apps - req/s and memory usage would be excellent to know.
Andi
It’d be great if others could also give phpng a quick try with their
apps and share results. That’ll help give us a bit more visibility
into the current impact for various apps - req/s and memory usage
would be excellent to know.Andi
I tried building it tonight on Ubuntu 12.04.4 LTS (GNU/Linux
3.8.0-37-generic x86_64). I got some make errors. Where should I report
those?
Brian.
It’d be great if others could also give phpng a quick try with their
apps and share results. That’ll help give us a bit more visibility
into the current impact for various apps - req/s and memory usage
would be excellent to know.Andi
I tried building it tonight on Ubuntu 12.04.4 LTS (GNU/Linux 3.8.0-37-generic x86_64). I got some make errors. Where should I report those?
I suggest you just send here so we can resolve quickly.
Thanks,
Andi
Hi!
Following the previous benchmarks post, I've added some benchmarks on
the same code for 64-bit patch. For master, I used the official branch,
for phpng, the mini-patch here:
https://gist.github.com/dstogov/07fcbb60b1b585bcd290 that of course does
not represent the whole 64-bit patch but reproduces its most significant
effects following the emerging consensus - making zval's string length
64-bit. I have also added memory peak stats both with and without
opcache (since opcache doesn't use emalloc it distorts the memory
picture a bit).
The results are here:
https://docs.google.com/spreadsheets/d/1O9gMH_L2rpvFPEVeOOvCmI8Z6-imaIuAw-V9XU19NZI/edit#gid=0
The results suggest that this minimal change - absent any others, and if
you believe this very simple and limited benchmark - while producing
definite memory increase, beyond margin of error in most cases, is not
too bad and at least on this limited example, does not cause performance
degradation to the NG patch.
Of course, this is only one app and it's not even the real patch but
just one (albeit controversial) aspect of it, so we'd need to be
careful, but I think this confirms that the consensus proposal (the one
Nikita outlined earlier) may be acceptable to go forward.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227