I developed the following CGI script and run on Apache 2 (http://localhost/test.chtml). I did same script in PHP (http://localhost/verifica.php). Later I performed Apache benchmark using Apache Benchmark tool. The results are showed in images.
include
#include <stdlib.h>
int main(void)
{
printf("%s%c%c\n",
"Content-Type:text/html;charset=iso-8859-1",13,10);
printf("<TITLE>Multiplication results</TITLE>\n");
printf("<H3>Multiplication results</H3>\n");
return 0;
}
Someone can explain me why PHP serves more requests than CGI script?
A call to a standalone CGI program results in a fork / exec - the new program has to be loaded completely. This is not very efficient.
Iniitially PHP ran this way, but to speed things up mod_php was developed, where the PHP interpreter ends up built-into and running inside the process space of the Apache server and all it has to do is some simple parsing.
The only thing that you're really measuring here is the overhead caused by an almost no-operation program. The overhead incurred by calling a script or a cgi depends on how your Apache server is configured. Chances are you're using php as a module, meaning that it actually runs inside the apache process. For the CGI you're probably using the regular flavor, ie a process is created for every call.
Depending on what you actually want to test/know/evaluate, you should probably rerun this test a number of times, eg with extensive calculations in php vs a C cgi, using fastcgi, and whatnot. Also, don't forget to check the impact of code caches like APC on the execution of the php code, for certain cases the difference is dramatic.
Related
I recently read about http://php.net/pcntl and was woundering how good that functions works and if it would be smart to use multithreading in PHP since it isn't a core function of PHP.
I would want to trigger events that don't require feedback through it like fireing a cronjob execution manually.
All of it is supposed to run in a web app written with Zend Framework
The pcntl package works quite fine - it just uses the according unix functions. The only shortage is that you can't use them if php is invoked from a web server context. i.e. you can use it in shell scripts, but not on web pages - at least not without using a hack like calling a forking script with exec or similar.
[edit]
I just found a page explaining why mod_php cannot fork. Basically it's a security issue.
[/edit]
This is not thread control, this is process control. The library for the threads is pthreads (POSIX threads) and it's not included in PHP, so there are no multi-threading functions in PHP.
As of multiprocessing, you cannot use that in mod_php, as that would be a giant security hole (spawned process would have all the web-server's privileges).
The only possible way to have php code executing in multiple threads is to run php as a module of a threaded web server, which is useless because threads are fully isolated and your code has no control over them. As far as i know, pcntl only manages processes, not threads.
If I needed to do manual crontab executions or the like from PHP, I'd probably use a queue. Have a database table that you append jobs to. Another process, either from a cron or running as a daemon, executes the jobs as they show up.
Another way to do it is to set up a separate script and do an HTTP GET to it. It's not quite threading, but it's one way of shelling to another command in PHP.
For example, if I wanted to run /usr/bin/somescript.sh on demand, I'd have a somescript.php that did a system call. This would be on a virtual host only accessible from localhost.
I'd do a socket call to the webserver and GET the script. The key is to not read on the socket so it doesn't block. If I wanted to check the return value of somescript.php, I'd do it later in my main script to prevent blocking.
If somescript.php takes a long time to execute (longer than the calling script), you'll have to do some magic to stop apache from killing the script when the socket is closed.
Multiplatform PHP Multithreading engine
http://anton.vedeshin.com/articles/lightweight-and-multiplatform-php-multithreading-engine
Examples of multithreading working in PHP (with excerpts from their project pages):
Cron Multi-Threaded.
As of October 25th, 2011, this module has reached "end of life" and is deprecated in favor of projects such as Elysia Cron. This module wasn't completely useless in that a core patch inspired by Cron MT was committed to D7.
Boost.
... provides static page caching for Drupal enabling a very significant performance and scalability boost for sites that receive mostly anonymous traffic. For shared hosting this is your best option in terms of improving performance. On dedicated servers, you may want to consider Varnish instead.
I'm running a linux web server that uses apache, php, and suphp. Each time a guest accesses the server, suphp is started, the php interpreter is started and the php file is processed, but all of these files are on the disk.
I want to make it so that when the suphp and php programs start for the first time, they get cached in memory, and then the next time (and times after that) they try to start again, they will load from memory, making the startup time much smaller.
I think there is a setting inside /proc somewhere that can help me with this, but I'm not sure which one.
What you're trying to change is an aspect of application behavior, not kernel behavior, so there is nothing in /proc that will help you.
PHP opcode caching is not available under suPHP. You will need to use something else (possibly mod_php or FastCGI) to take advantage of it.
In some programming languages like C,C++,c#,Java,..etc when the code is compiled then the code is converted into another form in order to execute it. Does the Apache do the same or just it executes it without any conversion?
Apache doesn't do anything except handle the incoming request and serve the resulting output. Everything else is done by the PHP interpreter which pre-compiles the PHP code to a bytecode form, and then executes the bytecode instructions.
Apache is just a webserver that may or may not be running with PHP as a module. It's better to think of the webserver as a mere mediator between the frontend and the php binary.
The latter is compiled, yes, but it runs your code without compiling. It is an interpreted language.
There are ways to accelerate php processing using some opcode cache or just in time compilers, but default PHP doesn't deal with that.
I recently read about http://php.net/pcntl and was woundering how good that functions works and if it would be smart to use multithreading in PHP since it isn't a core function of PHP.
I would want to trigger events that don't require feedback through it like fireing a cronjob execution manually.
All of it is supposed to run in a web app written with Zend Framework
The pcntl package works quite fine - it just uses the according unix functions. The only shortage is that you can't use them if php is invoked from a web server context. i.e. you can use it in shell scripts, but not on web pages - at least not without using a hack like calling a forking script with exec or similar.
[edit]
I just found a page explaining why mod_php cannot fork. Basically it's a security issue.
[/edit]
This is not thread control, this is process control. The library for the threads is pthreads (POSIX threads) and it's not included in PHP, so there are no multi-threading functions in PHP.
As of multiprocessing, you cannot use that in mod_php, as that would be a giant security hole (spawned process would have all the web-server's privileges).
The only possible way to have php code executing in multiple threads is to run php as a module of a threaded web server, which is useless because threads are fully isolated and your code has no control over them. As far as i know, pcntl only manages processes, not threads.
If I needed to do manual crontab executions or the like from PHP, I'd probably use a queue. Have a database table that you append jobs to. Another process, either from a cron or running as a daemon, executes the jobs as they show up.
Another way to do it is to set up a separate script and do an HTTP GET to it. It's not quite threading, but it's one way of shelling to another command in PHP.
For example, if I wanted to run /usr/bin/somescript.sh on demand, I'd have a somescript.php that did a system call. This would be on a virtual host only accessible from localhost.
I'd do a socket call to the webserver and GET the script. The key is to not read on the socket so it doesn't block. If I wanted to check the return value of somescript.php, I'd do it later in my main script to prevent blocking.
If somescript.php takes a long time to execute (longer than the calling script), you'll have to do some magic to stop apache from killing the script when the socket is closed.
Multiplatform PHP Multithreading engine
http://anton.vedeshin.com/articles/lightweight-and-multiplatform-php-multithreading-engine
Examples of multithreading working in PHP (with excerpts from their project pages):
Cron Multi-Threaded.
As of October 25th, 2011, this module has reached "end of life" and is deprecated in favor of projects such as Elysia Cron. This module wasn't completely useless in that a core patch inspired by Cron MT was committed to D7.
Boost.
... provides static page caching for Drupal enabling a very significant performance and scalability boost for sites that receive mostly anonymous traffic. For shared hosting this is your best option in terms of improving performance. On dedicated servers, you may want to consider Varnish instead.
I am planning to use php in an embedded environment. Our current web server is thttpd. I am considering two options now: whether to run it as a cgi or as SAPI module. I know cgi has advantage in terms of security. But if we are to use php as cgi, an instance of the php should be loaded into the memory for each request.
I have tried compiling it as a SAPI module of thttpd and I have observed that thttpd's memory usage, specifically rss, does not grow larger as the number of request increases.
Can anybody explain how thttpd loads php? Is it loaded just one time and stays resident to the memory as long as thttpd is running? If so, we may consider this as an alternative to cgi.
Does it perform multi-threading, i.e. if there's multiple http request at the same time? or does it process request one at a time?
Is there a good documentation discussing behavior of php as a module of thttpd?
I have no experience with thttpd, but here are some pointers:
the PHP engine is thread safe, but some extensions aren't, so usually people shy away from using it in a multi-threaded environment and rather go with the one-process - one-request method
yes, usually webserver modules (like the Apache mod_* stuff) works by staying resident, but the big speedbump for PHP is that it needs to parse the source file (or even multiple source files if you use include / require) for each request. You can cut down on this by using something like APC which caches the parsed version of the files
there is also a protocol called FastCGI which you might want to look at - it basically is a crossover between the module and CGI solution - it spins up a couple of processes, each process hosts a single instance of the CGI problem (PHP in this case) and uses them to process requests. Instances are recycled (ie. they can process multiple requests, one after the other).