FastCGI ?

[THL]

My hosting has installed FastCGI along with a newer version of PHP and APC for caching.

Forum seems a little slower compared to when I had just PHP and xcache on..

Would Fastcgi slow things down , I'm not the best on this sort of stuff??

[Steves Web Hosting]

I would expect FCGI would speed up an IPB site. That is one reason that sometimes drives that selection for PHP handler.

[p4guru]

depends on what you have previously as php handler

in terms of speed for standalone php handler

for apache based servers it would be from fastest to slowest

mod_php > fastcgi -> suphp -> cgi

so if your previous php handler was mod_php and you switch to fastcgi, then naturally you will notice slower speeds in general, probably so to the point adding back a php opcode cacher to pair with fastcgi isn't enough to make up the difference OR you don't have php opcode caching configured or installed correctly for use with fastcgi

[THL]

Just checked I previously had mod_php, now they have fcgi setup...it does seem slower..

[Gary.]

You should notice a big difference, mod_fcgi should serve you a lot faster php times. It could be that the mysql has not been optimized for FCGI.

You can tune your mysql and get it right for when you run suPHP or such but if you change the apache to something quicker then it's going to use mysql more, TMP tables, Queries and such will come in faster to run a mysql tuner and see what changes it suggests.

Gary.

[THL]

Hello Gary, swapped back to mod_php and its a lot quicker bud..

Although some would say less secure..

[Grumpy]

Good pre-read.
http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better-resource-utilization.html

If you find a heavily noticeable loss for using fcgi, I would think there are other problems that were raised by integration of fcgi rather than faulting fcgi itself.

[GIANT_CRAB]

Hello everypony,

FCGI eats up tons of resources, I do recommend all of you to use suPHP instead, for security and for less resources consumption.

But if its your first time using suPHP, remember to chmod ALL directories to 755, chmod ALL files to 644.

Yours truly,
GIANT_CRAB

[Grumpy]

Hello everypony,

FCGI eats up tons of resources, I do recommend all of you to use suPHP instead, for security and for less resources consumption.

But if its your first time using suPHP, remember to chmod ALL directories to 755, chmod ALL files to 644.

Yours truly,

GIANT_CRAB

WHAT?!?!?!?! Please don't spread false BS.
fcgi is the LEAST resource consuming. That's the purpose for fcgi.
suphp is THE MOST resource consuming. suphp runs each php under a different user which requires a separate process instead of threads. Security is their goal, and performance is the sacrifice made to achieve that.

[Rhett]

Let's not get into a fight over this please.... we all have opinions... and can state them in an effort to help others, each method has pro's and con's and also will have varying performance based on configuration of each. Personally I'm not a fan of FGCI at all. However your performance on any setup will be largely based on a proper setup.

[GIANT_CRAB]

WHAT?!?!?!?! Please don't spread false BS.

fcgi is the LEAST resource consuming. That's the purpose for fcgi.

suphp is THE MOST resource consuming. suphp runs each php under a different user which requires a separate process instead of threads. Security is their goal, and performance is the sacrifice made to achieve that.

Hello, in resources I meant memory, not CPU.

In terms of CPU, fcgi indeed is the best, I have to agree to that.

But for memory, FCGI eats up more than suPHP, around two times more than suPHP.

Both FCGI and suPHP has security, but I would prefer suPHP standardised security than to FCGI's security.

Please do not take my opinion as an insult towards your opinion.

I suggest reading up http://forums.cpanel.net/f5/switching-suphp-160421.html if you wish to know more about PHP handlers

Note: DSO (mod_php) is known to be very unsafe, uses cpu uneffectively but low memory usage, but DSO is the fastest.

Yours truly,
GIANT_CRAB

[Grumpy]

Well, this thread is about speed. Which ones gives the page out faster. Not who uses less ram.

And with load, fcgi can use less ram than suphp.

mod_php (aka dso) is a module built exactly for php for apache to handle. This very specific linking allows dso to be highly optmized in passing php very very fast. Thus, dso often wins in php benches. Problem is that it doesn't give a good security and forces everyone to run under "nobody".
cgi is the age old system, we can consider this "average" by all standards. This is very generic and can pass php or anything to anything. Very simple system. Gets what it needs to run and that's it.
suphp (single user php) runs cgi for php under each user. That means at LEAST of one process is required per user. This is an extreme overhead over threading method. On top of that, this behavior prevents usage of opcache like xcache or apc which is a HUGE downfall to performance. This is however often the best choice for shared environments b/c it gives the security benefit of other users' scripts not being able to modify your own. It also allows each file to have the users' own permissions. This IS the core of suphp's security boost and its performance downfall.
fcgi is like cgi but optimized to be faster. Under default setup of most OS distro or fresh build (cpanel does NOT carry default), fcgi does not run cgi under each user as it doesn't assume shared env. (cpanel does). So, it doesn't carry the each-user process over head. fcgi CAN be a memory hog because it holds onto the data that'll get used again. This is what allows the speed to be delivered AND what allows opcache to work inline with fcgi.

So, if we assume there's 1 process, fcgi would be using the most ram. No question.
BUT!! Under load, this often is a different story. A process that's over is bound to carry less ram than something that's still running. fcgi or dso with opcache can run as fast as 10x than cgi/suphp. So, if you compare the memory usage of 1 fcgi vs 10 suphp, fcgi wins quite marginally. Also, the memory overhead created by fcgi is shared among each php threads. It's not a direct one to one arithmetic increase of ram usage in fcgi unlike cgi based (unless someone tweaks it REALLY badly...). This is why opcache actually decreases memory load even though we're making memory caches. On my server, right now it uses under 2 gigs of ram for php processing. If I disable opcache, it will jump to 6~7 gigs and decrease stability. It's THAT significant.

And we can see this behavior (decrease of ram usage) being duplicated in other benches as well (where fcgi/higher ram-per run uses LESS ram in total)
http://www.brandontu...che_benchmarks/
http://www.apachelou...pic.php?p=10991
The two above and the one I linked in previous link is the only benches where ram was even mentioned that I could find.

And honestly, I would take numbers from 3rd party benches and my personal benches based on over million+ page views lot more reliable than someone on cpanel forums of who can't even control his own php mod.

[GIANT_CRAB]

Hello,

Beware, if you think suPHP and FCGI is the safest, it really isn't.

suPHP, FCGI and CGI are exposed to malicious attack, hack, exploit and injection because PHP run as the files ownership.

DSO has files permission problems, not recommended for shared hosting indeed.

Also, both of them do not allow PHP directives in .htaccess

FCGI is harder to manage compare to CGI and suPHP.

Finally, FCGI is only good for high traffic sites because PHP processes are running permanently even if no page is requested, this is faster and fine for a high traffic site but for a small homepage with 100 pageviews per hour you would waste resources.

If you really want SHAZBOT (maximum speed), just use DSO.

My point is, every handler has advantages and disadvantages and there is no handler which always better than another.

All the advantages and disadvantages of each php handlers will eventually EQUAL all of them.

Yours truly,
GIANT_CRAB

[THL]

I did go back to DSO and noticed performance increases immediately over FCGI..

What settings would I add to the likes of php.ini if I went back to FCGI for security to speed it up?

[Luis Manson]

no one uses php-fpm ?
http://php.net/manua...install.fpm.php

FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features (mostly) useful for heavy-loaded sites.

These features include:

• advanced process management with graceful stop/start;
• ability to start workers with different uid/gid/chroot/environment, listening on different ports and using different php.ini (replaces safe_mode);
• stdout and stderr logging;
• emergency restart in case of accidental opcode cache destruction;
• accelerated upload support;
• "slowlog" - logging scripts (not just their names, but their PHP backtraces too, using ptrace and similar things to read remote process' execute_data) that are executed unusually slow;
• fastcgi_finish_request() - special function to finish request and flush all data while continuing to do something time-consuming (video converting, stats processing etc.);
• dynamic/static child spawning;
• basic SAPI status info (similar to Apache mod_status);
• php.ini-based config file.
  

[p4guru]

no one uses php-fpm ?

http://php.net/manua...install.fpm.php

only use it when paired with nginx as a web server not apache... too lazy to compile php-fpm myself so when i need to set it up i just download Centmin Mod to auto install nginx, php-fpm, mariadb and apc and memcached :)

[Gary.]

Hello,

Beware, if you think suPHP and FCGI is the safest, it really isn't.

suPHP, FCGI and CGI are exposed to malicious attack, hack, exploit and injection because PHP run as the files ownership.

DSO has files permission problems, not recommended for shared hosting indeed.

Also, both of them do not allow PHP directives in .htaccess

FCGI is harder to manage compare to CGI and suPHP.

Finally, FCGI is only good for high traffic sites because PHP processes are running permanently even if no page is requested, this is faster and fine for a high traffic site but for a small homepage with 100 pageviews per hour you would waste resources.

If you really want SHAZBOT (maximum speed), just use DSO.

Sorry I would have to disagree !

FCGI can be same, Just as safe as suPHP it depends on how well you build the profile, Now there can be a weakness, That is where you use mod_sec, Also disabling functions within the php.ini, PHP does not have to run as ownership, Thats only when you use susexe, You can make it all run as root or even nobody, Or a custom name in which I use.

mod_fcgi hardly consumes anything, If it does then you have not optimized the php or mysql, Apache will use alot if the mysql if not keeping up, There are hundreds of factors to look at, suhosin is also secure, depends on what rules you put in place, Put them all in you have a secure fcgi, Again not all php applications can be run when it's to secure.

If your unsure on mod_fcgi then do not use it, If you have experience then you will have no issues.

The only weakness the mod_fcgi can have is the person that compiled it.

[GIANT_CRAB]

Sorry I would have to disagree !

FCGI can be same, Just as safe as suPHP it depends on how well you build the profile, Now there can be a weakness, That is where you use mod_sec, Also disabling functions within the php.ini, PHP does not have to run as ownership, Thats only when you use susexe, You can make it all run as root or even nobody, Or a custom name in which I use.

mod_fcgi hardly consumes anything, If it does then you have not optimized the php or mysql, Apache will use alot if the mysql if not keeping up, There are hundreds of factors to look at, suhosin is also secure, depends on what rules you put in place, Put them all in you have a secure fcgi, Again not all php applications can be run when it's to secure.

If your unsure on mod_fcgi then do not use it, If you have experience then you will have no issues.

The only weakness the mod_fcgi can have is the person that compiled it.

If you have read my post carefully, I mentioned that both suPHP and FCGI are not safe, none of the php handlers are safe at all.
They are all prone to attacks, just if its harder to attack, or easier to attack.
And FCGI is the hardest to manage, just like what I mentioned.

No, mod_fcgi weakness isn't that the its the hardest to manage, it also includes being proned to attacks.

No matter how secure or whatever addons you compile along with your apache, there is always a leak hole, in every single php handler.

:facehoof:

[Gary.]

Harder to manage, Only chmod then things should be fine.

His host is putting him on that profile for a reason, Speed based, His first post said:

My hosting has installed FastCGI along with a newer version of PHP and APC for caching.

Forum seems a little slower compared to when I had just PHP and xcache on..

If you still have x-cache on in your conf_global then you will see sluggish things. Just remove the line as you may not have x-cache enabled no more.

check in your ACP and copy / paste the contents of his enabled modules for the server.

[THL]

I did have FCGI and xcache enabled and noticed things were much slower.

So I reverted back to DSO and xcache and things were much faster.

Heres my php loaded extensions.

Core, PDO, Phar, Reflection, SPL, SQLite, SimpleXML, XCache, Zend Guard Loader, apache2handler, bcmath, calendar, ctype, curl, date, dom, ereg, exif, filter, ftp, gd, gettext, hash, iconv, imap, ionCube Loader, json, libxml, mbstring, mcrypt, mysql, mysqli, openssl, pcre, pdo_mysql, pdo_sqlite, posix, session, soap, sockets, sqlite3, standard, timezonedb, tokenizer, xml, xmlreader, xmlwriter, zip, zlib

I do also use mod_sec, what other simple things would you recommend to increase security?

[GIANT_CRAB]

I did have FCGI and xcache enabled and noticed things were much slower.

So I reverted back to DSO and xcache and things were much faster.

Heres my php loaded extensions.

Core, PDO, Phar, Reflection, SPL, SQLite, SimpleXML, XCache, Zend Guard Loader, apache2handler, bcmath, calendar, ctype, curl, date, dom, ereg, exif, filter, ftp, gd, gettext, hash, iconv, imap, ionCube Loader, json, libxml, mbstring, mcrypt, mysql, mysqli, openssl, pcre, pdo_mysql, pdo_sqlite, posix, session, soap, sockets, sqlite3, standard, timezonedb, tokenizer, xml, xmlreader, xmlwriter, zip, zlib

I do also use mod_sec, what other simple things would you recommend to increase security?

Add suhosin.
If your curl is not ssl, i suggest to change it to curl ssl.
Good that you have zend guard and ioncube loader.

The reason why DSO is faster because it is used as a module and not CGI and with xcache, you achieve infinite profit.
Also, you shouldn't really reveal stuffs about your php build.

[THL]

Add suhosin.

If your curl is not ssl, i suggest to change it to curl ssl.

Good that you have zend guard and ioncube loader.

The reason why DSO is faster because it is used as a module and not CGI and with xcache, you achieve infinite profit.

Also, you shouldn't really reveal stuffs about your php build.

What does suhosin actually do and will it effect performance at all? I know when I first implemented mod_sec a lot of rules were being triggered anb blocking many people from the site until I whitelisted certain ones..

[GIANT_CRAB]

it just pretty much increase security.
max variables are set to 1000.
max length of post is limited to 100000.
etc, around there.

[Gary.]

What does suhosin actually do and will it effect performance at all?

These values are needed for IPB to run well in suhosin.

[suhosin]

suhosin.post.max_vars = 4096

suhosin.request.max_vars = 4096

suhosin.post.max_value_length = 100000000

suhosin.request.max_value_length = 100000000

suhosin.request.max_varname_length = 4096

suhosin.get.max_value_length = 100000

suhosin.get.max_name_length = 100000

Some values I put are not mentioned by IPB but adding and adjusted them ran fine on big title names or such.

Gary.