Forum

Hiawatha version: 9.2
Operating System: FreeeBSD9.0p1-i386

Hello Hugo,

I've been doing some tests using ab in 2 VPS (1 local, 1 remote...both hostd in a linux KVM box).

Same OS , same multiple PHP(cgi) versions compiled with the same arguments and with the same extensions.
I report mean results for Apache 2.2.1 (A) and Hiawatha (H) 8.2 (compiled from source, no-debug/stripped):

cmd = ab -c 100 -n 1000 $address (issued locally)

1. Simple html file printing "Hello"

A = Requests per second: ~1900 [#/sec] (mean) / no failures
H = Requests per second: ~1700 [#/sec] (mean) / no failures

2. PHP info file

A = 0 failures
H = about 10%~25% failures

A:
uses mod_fcgid to spawn php processes, the script that start php-cgi binary uses the same parameters as H setups excluding PHP_FCGI_CHILDREN which is in this case always set to 0.

H:
I tried with php-fcgi, spawn-fcgi (both command line and supervised by daemontools) and as daemontools supervisd script (run script start php-cgi binary with binding options) with different PHP_FCGI_CHILDREN setup (0, 1,3,9)

What am i doing wrong? Shouldn't H be faster at least when serving static files being so small and clean?

Thanks fro your work,
Best regards,

Maks

UPDATE: Hiawatha 8.3

I found the new source. I compiled and tested the binary with the same configuration of the previuous post. Now it can handle requests up to:

ab -c 193 -n 1000(0) ${fqdn.tld}/phpinfo.php without failures

I noticed that repeating this test a few times increases hiawatha memory to 50~100MB quickly.

0) start with 3192k
1st) ab -c 100 -n 1000 domain/phpinfo.php => ~ 22M
2nd) ab -c 100 -n 1000 domain/phpinfo.php => ~ 32M
3rd) ab -c 100 -n 1000 domain/phpinfo.php => ~ 39M
4th) ab -c 100 -n 1000 domain/phpinfo.php => ~ 42M

Is there a way to prevent this?

Thank You.

What method do you use to measure the memory usage?

Can you show me your configuration?

Hello Hugo, I use

top -U www (i run hiawatha - and some of the php-cgi processes - as www:www 80:80 in FreeBSD)

the RESident column

VERY BASIC H CONFIGURATION
http://castor.feliks.org/hiawatha.conf
2 FastCGIServer
php-08053 port 8053 for php procs started spawn-fgci (either manually or under daemontools)
php-10053 port 10053 for php-cgi started directly by daemontools(setuidgid): http://castor.feliks.org/run

http://castor.feliks.org for details on php installed modules - basic + xcache + suhosin - (now running under apache-22+mod_fcgid...but PHPRC and php-cgi binary are the same as Hiawatha conf)

Hiwatha compiled using the following setup script: http://castor.feliks.org/cfg-hiawatha.sh

Best regards,

Maks

Oh i forgot to say, i increased the Hiawatha max connections parameters on order to not get kicked out during ab tests

Can I see the contents of the files in /usr/local/etc/hiawatha/toolkits and /usr/local/etc/hiawatha/vhosts?

Can I also see the output of your ab runs?

Just a couple of toolkits silverstripe + yii (exact copy from your site example toolkits), vhost dir has 1 empty file "test.vhost", but the results are the same in my local computer VPS (i built another one under VirtualBOX just to be sure...) (same OS - php - hiawatha version without vhosts/toolkits added).

I just finished testing nginx with the same php configuration (using the 10053 port php process):
nginx RES remains at 4252K even after 4~5 ab runs.

The limit for failures for phpinfo in nginx setup is 193, as for hiawatha (using the 10053 port php process):
TESTING HIAWATHA/NGINX in my local VPS (freebsd-9.0-i386p1/vbox/1024MB/1cpu...same results as local kvm and remote kvm)

# HIAWATHA top RESULTS/ab RUNS (http://castor.feliks.org/hiawatha-local-vps.conf)
31482 www 2 20 0 12836K 3192K nanslp 0:00 0.00% hiawatha
ab -c 150 -n 5000 http://freebsd9.vbox.bsd/phpinfo.php (http://castor.feliks.org/ab-hiawatha.txt)
31482 www 2 20 0 104M 41320K nanslp 0:03 0.00% hiawatha
ab -c 150 -n 5000 http://freebsd9.vbox.bsd/phpinfo.php (2nd run)
31482 www 2 20 0 104M 60628K nanslp 0:07 0.00% hiawatha

# NGINX top RESULTS/ab RUNS:
31703 www 1 52 0 10248K 2672K kqread 0:00 0.00% nginx
ab -c 150 -n 5000 http://freebsd9.vbox.bsd/phpinfo.php (http://castor.feliks.org/ab-nginx.txt)
31703 www 1 52 0 10248K 3864K kqread 0:02 0.00% nginx
ab -c 150 -n 5000 http://freebsd9.vbox.bsd/phpinfo.php (2nd run)
31703 www 1 52 0 10248K 3864K kqread 0:04 0.98% ngin

Regards,
Maks

Could you please follow these instructions for me? I tried to reproduce the leak, but whatever I try, Hiawatha runs just fine here.

My suggestions for settings of Maks : fastCGI seems to be better at serving dynamic contents rather than static ones, so maybe use webserver to serve html file directly would provide more accurate results;
Hiawatha has its own fastCGI managing tool, which can greatly enhance the performance of Hiawatha webserver, so use php-fcgi which comes along with Hiawatha instead of tools from third parties.

Hello Ginghong,

apparently, after some tests with Hugo, it seems that only FreeBSD (9.0-i386-p1) has this issue and seems related to the freebsd pthread libraries.

I made tests serving both static and dynamic content: they always suffered from memory usage increase even if serving php showed bigger increases (but could also be related to the length of the page served i will do some other tests next week).

As far as fastcgi goes: php-fcgi, spawn-fcgi, or simple shells scripts are all tools to run the php-cgi binary (+ calling setuid() ), binding it to a socket or ip/port. In the end they always set env variables and call php-cgi with needed parameters. The so called thirty party tools "daemontools" are just process monitor utilities to keep php-cgi instances running in case of crashes.

In my case, as djb tools comes with setuidgid utility, i don't need other apps to do that (but used them just to compare tests). You can also make test just launching the php-cgi binary itself with parameters from the command line and when done, ctrl-c it.

For what i understood, php-fcgi uses 1 configuration file with multiple cfg line 1 per php-cgi instance. But I think it's not possible to shut down / restart just 1 instance. You killed them all. The solutionis to start many php-fcgi instances with different conf files. Again in my setup i need to pass dfferenet PHP_FCGI_* , ENV,
and php-cgi parameters per website, so i will end up with the following solution (1 per site)

A)
-monitoring tool
-script which set some parameters and calls
-php-fcgi which reads
-1 php-fcgi conf file to set user, socket/addr-port/forks/children and starts
php-cgi

(but i need to pass long -d lines to the php-cgi binary)

B)
-monitoring tool
-script which set some parameters and calls
-spawn-fcgi which set user, socket/addr-port, children, forks and starts
-php-cgi (with custom website -d flags)

C)
-monitoring tool
-script which set all needed parameters and calls setuidgid and
-php-cgi (with custom website -d flags)

In my case choice C is the simplest

This is the only thing i miss of apache - mod_fcgid - it has its own process manager - it starts php-cgi through a wrapper script (shell script owned by the website system user) and after a tunable period of time o num requests it shuts it down and starts another instance. So you don't need to have 1 php-cgi process per user (or per website), always running in background: mod_fcgi start the wrapper script when needed. Also no PHP_FCGI_CHILDREN are needed.

Another possibility is php-fpm with its pool of connections, but so far i've not tested it yet. As i run php 52,53,54 on the same server i want a uniform way to run php-cgi and to use php-fpm you need to patch v. 5.2.17, use the "experimental" feature of 5.3 or the finally production feature in 5.4. But as i said, i still haven't tested it... but i will.

Regards,
Maks

UPDATED valgrind leak-check(s) for FreeBSD:

Hello Hugo....some tests during free-time:

HIAWATHA STARTUP

==14931== 9,534 (232 direct, 9,302 indirect) bytes in 1 blocks are definitely lost in loss record 35 of 35
==14931== at 0x5BF98: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==14931== by 0x80591E6: default_config (serverconfig.c:245)
==14931== by 0x804FDF9: run_server (hiawatha.c:1449)
==14931== by 0x8050925: main (hiawatha.c:1927)

232 == sizeof(t_config) with my make params ...will search the corresponding lines to see why mem is not free(d)

9,534 bytes: could this represents memory increase in subsequent calls while serving static files, i.e. creating t_config pointers? Or is it just created once at server startup?

CALL TO phpinfo.php all resulting threads (3-4) equal:

==14932== Thread 4:
==14932== Syscall param socketcall.connect(serv_addr..sa_len) points to uninitialised byte(s)
==14932== at 0x1D634B: __sys_connect (in /lib/libc.so.7)
==14932== by 0x804B9A6: connect_to_fcgi_server (cgi.c:607)
==14932== by 0x805E001: execute_cgi (target.c:651)
==14932== by 0x804F34B: serve_client (hiawatha.c:724)
==14932== by 0x804FBD4: connection_handler (hiawatha.c:994)
==14932== by 0x8D4B9: ??? (in /lib/libthr.so.3)
==14932== Address 0xbf677dc2 is not stack'd, malloc'd or (recently) free'd

Regards,

Maks

SOLVED: it's a bug in the pthread library [svnweb.freebsd.org] in FreeBSD 9.0.