1

I add the header function in the hello.php sample, as below:

<?php
   header("xxxxx: yyyyy");
   fwrite(STDOUT, "see headers.<br><br>Hello, PHP!<br>current working directory: ".getcwd());
   exit(200); // return an HTTP code (200:'OK')
?>

but there is no such header found in firebug.
Who can explain how to add additional headers in php cli with gwan?

Gil
  • 3,279
  • 1
  • 15
  • 25
k.k. lou
  • 1,805
  • 2
  • 13
  • 16
  • If you're running the CLI sapi, there there's no way to set headers - why on earther would anyone running a super-fast content server want to connect it up to PHP via the slowest possible interface? – symcbean Jan 22 '13 at 12:43
  • if so, should i add headers by gwan's handler? – k.k. lou Jan 22 '13 at 12:54
  • Really you should be using fastCGI - but IIRC there's not an officially supported plugin for the GWAN side (the joys of closed source development) – symcbean Jan 22 '13 at 12:56
  • Gwan makes php fly. Gwan benchmarking showing php has the speed of about 600k req/s (in a xeon w3680 3.33GHz). Although it is slower than gwan with native c servlet, it is fast enough to meet my needs. With php, I can use gwan right now. But with c, i need time to learn. – k.k. lou Jan 22 '13 at 13:05
  • From the G-WAN blog: "G-WAN is using PHP in the worse possible way (by invoking it as an extern process, and therefore not caching compiled code)" – symcbean Jan 22 '13 at 13:29
  • thanks to symcbean. Will consider your findings. Will keep an eye on the cpu and memory usage. – k.k. lou Jan 22 '13 at 14:54
  • 1
    Have you tried adding it in fwrite like fwrite(STDOUT, "xxxxx: yyyyy\r\n\r\nSee headers....")? In C G-WAN will not add headers if there's already a header on the reply. – Richard Heath Jan 22 '13 at 15:17
  • See this almost identical question: http://stackoverflow.com/questions/14357907/g-wan-output-headers-from-cgi-script – thwd Jan 22 '13 at 16:06

2 Answers2

2

Thanks to Gil and Richard,
Now, it is what i did according to your advices. PHP works in gwan with customized headers.

<?php
 $output='See headers....Hello, PHP!<br>from gwan';
   $len=strlen($output);
   fwrite(STDOUT, "HTTP/1.0\r\nContent-Type: text/html; charset=UTF-8\r\nConnection: close\r\nContent-Length: $len\r\nxxxxx: yyyyy\r\n\r\n$output");
    exit(1);
?>

i use ab -c 1000 -n 100000 http:127.0.0.1/?hello.php
The memory usage is increased by 0.7% of 2.9GiB = 0.0203GiB
The CPU usage is increased from 20% to 75% = 50% (ab run in the same machine with gwan)
I did it in my old machine intel P9300 2.26GHz x 2, ubuntu 12.04

it finished in 9.543 sec without failure
about 10,479 req/sec

k.k. lou
  • 1,805
  • 2
  • 13
  • 16
  • 2
    For an **Intel Core2 Duo P9300 @ 2.26GHz [passmark score: 1509]**: http://www.cpubenchmark.net/cpu.php?cpu=Intel+Core2+Duo+P9300+%40+2.26GHz, this is not bad (recent CPUs are 10x more powerful). Note that this PHP script will run much faster if you let G-WAN generate the HTTP headers by using exit(200); instead of exit(1); – Gil Jan 26 '13 at 07:18
0

Tom is right. To bypass the HTTP headers injected by G-WAN (because you returned 200) you should return a value in the 1-99 range (an invalid HTTP status code).

Then, you own HTTP headers (if any) will be used.

return 0; means close connection and return 200-600; is reserved for HTTP return codes that tell G-WAN to generate the correspondig HTTP headers.

The PDF manual is a resource worth reading.

Just a word about "fastCGI": it will NEVER be faster than running scripts in parallel from several threads... without ever involving the network (between the server and PHP).

The more intermediate layers or interfaces you add, the slower things will be so as "fastCGI" runs scripts via an interface using the network is necessarily slower than running the code directly (and I am not even addressing the fact that the PHP "fastCGI" server is very slow, that the fastCGI protocol iself is pointlessly complex and therefore slow, and that, on the top of that, the fasctCGI implementation is more than sub-optimal).

Now we have multicore CPUs, parallelism does not necessarily involve HORIZONTAL scalability (the scalability obtained by running code on many connected machines).

It is way cheaper (faster and more energy efficient) to scale VERTICALLY (on the many CPU Cores that reside on the local machine).

As the number of CPU Cores is growing exponentially, there is no way back: scaling VERTICALLY will make more and more sense as time goes.

Gil
  • 3,279
  • 1
  • 15
  • 25