FAQ
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:
1. lighttpd with fcgi driver
2. Single process PHP: sapi/cgi/php-cgi -b 9999
3. 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'
4. SugarCRM 6.7.4
5. 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

Search Discussions

  • Andi Gutmans at May 16, 2014 at 12:29 am

    On May 15, 2014, at 5:12 PM, Stas Malyshev wrote:

    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
  • Brian Moon at May 16, 2014 at 4:00 am

    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.
  • Andi Gutmans at May 16, 2014 at 4:16 am

    On May 15, 2014, at 8:59 PM, Brian Moon wrote:

    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
  • Stas Malyshev at May 20, 2014 at 8:24 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 16, '14 at 12:12a
activeMay 20, '14 at 8:24a
posts5
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase