I am using PHP 5.x with IIS webserver. I am going to use multithreading concept. Can anyone please tell me which PHP interface is more efficient, CLI or CGI and is there any major difference between these two for query executions?
As pointed out in the comments by #apokryfos CLI stands for Command Line Interface which is used when you execute PHP from say a Terminal/Shell (like bash).
CGI is Common Gateway Interface which is the interface between a web server and your application.
There are three ways you can interface PHP from a web server (ordered from slowest to fastest):
php-cgi uses CGI
php-fastcgi uses FastCGI
php-fpm also uses FastCGI but is more powerful than php-fastcgi.
php-cgi is pretty much outdated, and only used if you need simplicity and don't really care about performance.
php-fastcgi is better, but you should really use php-fpm if you want the best performance.
Related
I have large photo file and would like to use gwan as it fast. Is there any performance benefits in comparison to nginx fast-cgi. Does gwan fast at timd to first byte? Is it faster at connecting time? Is commputing time faster? Is throughput faster?Furthermore can you install hhvm on gwan. If you can, how would you install hhvm?would it give a performance benefit to php(how much)?
The only way you are going to know if nginx or G-WAN are better for your use case is to actually use them for your site and benchmark it. The speed of software like this depend very much on your configuration, usage patterns, site structure, etc etc, and is not something where a single blanket answer is appropriate or useful.
HHVM can be used behind any webserver which can serve FastCGI requests. A quick google search indicates that G-WAN may not support FastCGI, but rather has its own custom scripting interface? If so, it may still be possible to use that interface to integrate HHVM, though it is likely to require some work and not be officially supported.
The downside of FasCGI is that it's itself a backend server: instead of having only G-WAN as a server, you are limited by the speed of the backend server when G-WAN sends it requests and waits its replies:
Internet LAN
[clients] ============ [G-WAN] ----------------- [FastCGI + PHP]
latency1 latency2 latency3 latency4 latency5
In this case, the latency of a FastCGI server and the extra LAN latency are slowing-down G-WAN.
A more efficient way is to have G-WAN load and run the HHVM itself, which has been done with PH7, another thread-safe PHP runtime provided with G-WAN v4+:
Internet
[clients] ============ [G-WAN + PHP]
latency1 latency2 latency3
It is technically possible to implement *.hhvm G-WAN scripts like it has been done for G-WAN *.ph7, *.java, *.scala and *.cs (C#) scripts. This requires writting a G-WAN C module to load the HHVM in the G-WAN memory-sapce (something that may take time depending on the level of support provided by the Facebook HHVM team).
One could also use the G-WAN CGI interface to invoke HHVM as a local process (like G-WAN was forced to do for the thread-unsafe Zend PHP). But the results in terms of performance greatly depend on the initialization and processing times of the HHVM executable (not to mention the extra per-request overhead). This third way is simpler to implement but necessarily slower than a native HHVM G-WAN module.
I'm in the process of setting up a webserver from scratch, mainly for writing webapps with Python. On looking at alternatives to Apache+mod_wsgi, it appears that pypy plays very nicely indeed with pretty much everything I intend to use for my own apps. Not really having had a chance to play with PyPy properly, I feel this is a great opportunity to get to use it, since I don't need the server to be bulletproof.
However, there are some PHP apps that I would like to run on the webserver for administrative purposes (PHPPgAdmin, for example). Is there an elegant solution that allows me to use PyPy within a PHP-compatible webserver like Apache? Or am I going to have to run CherryPy/Paste or one of the other WSGI servers, with Apache and mod_wsgi on a separate port to provide administrative services?
You can run your PyPy apps behind mod_proxy and serve static content with Apache (or even better use nginx). In addition to CherryPy, gunicorn and tornado run great on PyPy.
I know that mod_wsgi doesn't work with mod_php
I heavily advise you, running PHP and Python applications on CGI level.
PHP 5.x runs on CGI, for python there exists flup, that makes it possible to run WSGI Applications on CGI.
Tamer
I have written a web server that servers html,js,css,images etc using C. I want to develop it that it has the capability to server PHP content also.
In that case I think I want to pass the PHP content to PHP preprocesser dynamically. How to call the PHP preprocesser.( I am using Ubuntu)
The easiest way is to invoke the PHP-CGI binary and communicate with that. Here is an example implementation in PHP, but it's quite simple in C as well:
http://nanoweb-instant.googlecode.com/svn/trunk/modules/mod_cgi.php (advisable)
http://nanoweb-instant.googlecode.com/svn/trunk/modules/mod_fcgi.php (avoid)
FastCGI is indeed faster, but is a fugly procotol. So I would recommend to avoid it. (SCGI is nicer, but not available for PHP).
If you really must, then look into http://www.fastcgi.com/drupal/node/5 for a readymade C-library for this purpose.
You could process the PHP file through the command line functions.
http://www.php.net/manual/en/features.commandline.options.php
I believe you would do; php -f <file>
I recommend you to implement the FastCGI protocol. PHP can be run as FastCGI, as well as other scripting languages. This makes it possible to have PHP processes running as daemons, which speeds up page access times compared to traditional CGI and commandline calls.
The best possible way to do this is to implement CGI or FastCGI, which PHP both supports
You could communicate with the PHP interpreter through FastCGI. This should perform better than calling php for each request.
I'm developing a web app for an Apache shared hosting server. I have already written some code in Perl but I recently found out, to my surprise, the shared hosting provider does not provided mod_perl or a way to install it.
I have been a bit worried that running a Perl web app through CGI without mod_perl would make it very slow? Should I switch all of my code to PHP instead, would that be faster?
The reason I chose Perl in the first place is, I'm very familiar with Perl more than PHP. Also I wanted to be able to use my Perl libraries outside the realm of web development.
So if any of you are experienced with Apache web development, can you shed some light as to which direction should I take.
For the sake of this question, lets say the web application will get 500+ hits a day.
Which would be faster PHP or Perl without mod_perl?
Thanks in advance for the help.
At only 500 hits a day, you could write your code in just about anything and not have to worry about slow downs. 500 hits a day evens out to about 1 page every 3 minutes. Even assuming a non-normal distribution of hits, you shouldn't really worry about this with such small traffic numbers.
PHP would be faster.
However, with only 500 hits per day, using cgi would not be a problem. Not even with 500 hits an hour.
Much depends on your architecture. Modern Perl frameworks aren't well suited for use as CGI (long start-up times). If you use CGI, Catalyst probably is a bad idea. That said, using classical architecture it should be quite manageable.
Unless your shared host is running PHP as a CGI application (not mod_php or FastCGI), PHP is almost1 always going to be faster. While Perl, running as a CGI, could probably handle your 500 hits a day, an application/page developed with CGI is going to be sluggish.
CGI works by spawning a new process to run your program for each request. Both mod_php and FastCGI applications mitigate this by spawning a set a number of processes and then using these to run your application. In other words, a new processes isn't being spawned for each request. (This is an oversimplified explanation, please don't use in a CS Term Paper. See mod_php and FastCGI docs for more info)
You could come up with pathological examples where it wouldn't be, but then you'd be the kind of person to come up with pathological examples of things, and no one wants that
Speed shouldn't be your concern. Both languages are suitable for web applications.
For the volume of traffic you're looking at, Perl with vanilla CGI shouldn't be an issue, although I would second the earlier recommendations to check out FastCGI as another option which your hosting service may provide.
Or another option would be to look for a different hosting company...
Expanding on what Alan Storm said, you might be able to use Perl with FCGI instead.
FCGI works by having a sort of stand-alone server, a daemon if you like, that connects with your web server via FCGI protocol and delegates/dispatches requests.
This is faster than normal CGI, as this emulates a sort of "servlet" model, the application is persistent, and there is no need for a new initialization on every call like there is with normal CGI.
I have not yet learned how to do this myself, but I believe Catalyst has this option, so its just a matter of learning how to replicate this.
FastCGI/FCGI should be available on drastically more hosts than plain old mod_perl, as FCGI applications are not web-server specific, and some web servers implement PHP via a fcgi utility.
And I've experimented with FCGI webserving a little, and preliminary tests say it can handle at least 500 req/s , far faster than the above concerns of 500/day or 500/hour.
It's possible to hack fastcgi support into a hosting account that doesn't support it. I compiled the fastcgi library with the install prefix set to the same thing as the home directory on the hosting account. Then I synced it up and set up catalyst to use the small cgi-fcgi bridge. It worked well. Nice and fast, because the cgi bridge is just a tiny little executable. The catalyst process persisted in the background just fine.
The answer in everyones mind is: who cares.
500 requests per day is nothing.
Just use whats fastest to implement / maintain and move on.
For lighter web frameworks that will work using CGI then have a look at....
Squatting
CGI::Application
CGI::Lazy
It depends mostly on how complex your code is and how it's put together; if you run it as CGI, perl will compile your script and modules on each invocation, and will have to reconnect to your database for each request. If your code is complex enough, this may take a few seconds per pageview, which may hamper user experience.
If your codebase and used modules isn't huge though, there should be no problem at all.
You can do a perl -c on your code to get a feel for how long perl startup and your compilation time is.
E.g. Is it more secure to use mod_php instead of php-cgi?
Or is it more secure to use mod_perl instead of traditional cgi-scripts?
I'm mainly interested in security concerns, but speed might be an issue if there are significant differences.
Security in what sense? Either way it really depends on what script is running and how well it is written. Too many scripts these days are half-assed and do not properly do input validation.
I personally prefer FastCGI to mod_php since if a FastCGI process dies a new one will get spawned, whereas I have seen mod_php kill the entirety of Apache.
As for security, with FastCGI you could technically run the php process under a different user from the default web servers user.
On a seperate note, if you are using Apache's new worker threading support you will want to make sure that you are not using mod_php as some of the extensions are not thread safe and will cause race conditions.
If you run your own server go the module way, it's somewhat faster.
If you're on a shared server the decision has already been taken for you, usually on the CGI side. The reason for this are filesystem permissions. PHP as a module runs with the permissions of the http server (usually 'apache') and unless you can chmod your scripts to that user you have to chmod them to 777 - world readable. This means, alas, that your server neighbour can take a look at them - think of where you store the database access password. Most shared servers have solved this using stuff like phpsuexec and such, which run scripts with the permissions of the script owner, so you can (must) have your code chmoded to 644. Phpsuexec runs only with PHP as CGI - that's more or less all, it's just a local machine thing - makes no difference to the world at large.
Most security holes occur due to lousy programming in the script itself, so it's really kind of moot if they are ran as cgi or in modules. That said, apache modules can potentially crash the whole webserver (especially if using a threaded MPM) and mod_php is kind of famous for it.
cgi will be slower, but nowadays there are solutions to that, mainly FastCGI and friends.
What is your threat model?
From the PHP install.txt doc for PHP 5.2.6:
Server modules provide significantly better performance and additional
functionality compared to the CGI binary.
For IIS/PWS:
Warning
By using the CGI setup, your server is open to several possible
attacks. Please read our CGI security section to learn how to defend
yourself from those attacks.
A module such as mod_php or FastCGI is incredibly faster than plain CGI.. just don't do CGI. As others have said, the PHP program itself is the greatest security threat, but ignoring that there is one other consideration, on shared hosts.
If your script is on a shared host with other php programs and the host is not running in safe mode, then it is likely that all server processes are running as the same user. This could mean that any other php script can read your own, including database passwords. So be sure to investigate the server configuration to be sure your code is not readable to others.
Even if you control your own hosting, keep in mind that another hacked web application on the server could be a conduit into others.
Using a builtin module is definitely going to be faster than using CGI. The security implications depend on the configuration. In the default configuration they are pretty much the same, but cgi allows some more secure configurations that builtin modules can't provide, specially in the context of shared hosting. What exactly do you want to secure yourself against?