DSO (mod_php) vs. CGI vs. suPHP vs. FastCGI

January 27, 2011 — 98 Comments

This is one of the most common topics that I see customers will ask about. As highly important as PHP handlers are, they often the least understood. They seem complicated, but its not too hard to understand. You don’t have to know that exact science of how it all works, but one should learn the basics if you want to take your website seriously. Picking the right PHP handler for your website will give you the optimal speeds you want and maybe allow you to save some money by using a cheaper hosting package. So I invite you to take a few minutes and learn something new.

What are PHP handlers

In order to run a PHP site, the server must interpret the PHP code and generate a page when visitors access the website. It interprets the code based on which PHP library you are using, such as PHP 4 or PHP 5. A PHP handler is what actually loads the libraries so that they can be used for interpretation. PHP handlers determine how PHP is loaded on the server.

There are multiple different handlers that can be used for loading PHP: CGI, DSO, suPHP, & FastCGI. Each handler delivers the libraries through different files and implementations. Each file and implementation affects Apache’s performance, because it determines how Apache serves PHP.

It is critical for your server’s performance that you select the handler that fits your situation. Selecting the right handler is just as important as the PHP version itself. One handler is not necessarily always better than another; it depends on your unique setup. What caching do you need, what modules do you need, etc…

  • Note: You may assign different PHP handlers to different versions of PHP. For example, version 5 may be handled by CGI while PHP 4 is handled by DSO.

How to change the handler

Changing the handler on cPanel is very easy to do and only takes seconds. Log into WHM and navigate to: Main >> Service Configuration >> Configure PHP and SuExec

You simply select your PHP handler choice from the drop-down menu. Then hit “Save New Configuration”.

  • Note: If you do not see your desired choice in the drop-down menu, it may need to be compiled on the server first. Run an “Easy Apache” to compile it.

List of PHP handlers

DSO (mod_php)

DSO is also known as mod_php. DSO stands for: Dynamic Shared Object. This is an older configuration but is generally considered the fastest handler. It runs PHP as an Apache module. This means that PHP scripts will run as the Apache user, which is the user: ‘nobody’.

DSO has two drawbacks. First, all files created by a PHP script will have the ownership of ‘nobody’. They will not be readable from the web. Websites that need to upload files through PHP will run into file permission issues. This is common with WordPress users that upload files through the WordPress interface or utilize the auto-update feature. These will fail with DSO.

The second drawback is a security issue. Created files will have the ‘nobody’ ownership. If a hacker finds an exploit in your PHP script, they could implement a file that has the same privileges as important system files that are also owned by ‘nobody’. This will give them the ability to modify files outside of that user’s account. This is really bad for anyone who does reselling or simply is hosting other person’s sites. You would not one user to be able to affect another user. However, if there is only one account on the server (or if all the accounts are yours), then DSO may be right for you. The speeds benefits of DSO are unquestionable.

An easy way to prevent the hack issue is to always keep your site’s software up to date. Check with your PHP script’s developer to keep up on the new releases. If you are the only one being hosted on the server, this is easy to do as it’s part of your webmaster duties already. However, if you’re reselling, it would be unreasonable to expect all your user’s to keep their software up to date. They simply may not be as diligent as you.

DSO’s low CPU usage typically amounts in higher speeds and load times over most other handlers. It is also the default setting on most servers.


CGI stands for: Common Gateway Interface. The CGI handler will run PHP as a CGI module as opposed to an Apache module. CGI still runs PHP processes as the Apache ‘nobody’ user. However, if you have suEXEC enabled, it will allow you to see the user that made the request.

The CGI method is intended as a fallback handler for when DSO is not available. According to cPanel’s own documentation, this method is neither fast nor secure, regardless of whether or not suEXEC is enabled.



suPHP stands for Single user PHP. suPHP also runs PHP as a CGI module instead of an Apache module. It differs from CGI in that PHP scripts that are called from the web will run under the user that owns them, as opposed to ‘nobody’. suPHP is typically the default handler and is recommended by cPanel for serving PHP because you will be able to see which user owns the account that is running the PHP script.

suPHP is beneficial in that if you are using a file upload tool on your site (such as an automatic updater or theme/plug-in installer for WordPress), the files will already have the right ownership & permissions. Uploading and other WordPress functions will not work without suPHP or FastCGI.

suPHP also offers a security advantage that any php script that is not owned by the particular user (such as another account or root) will not be executable. Also, files that have permissions set to world writeable will likewise be non-executable. This means that if one account is compromised, the malicious scripts will not be able to infect other accounts.

The drawback is that suPHP generally runs a much higher CPU load. In addition, you CANNOT use an Opcode Cache (such as Xcache or APC) with suPHP. It is strongly recommend that you install a caching plug-in to supplement this ned. If you find that your server is still continually struggling with CPU usage, you will want to consider switching to DSO or FastCGI.

*If you DO switch to either suPHP or FastCGI, you will need to update the file permissions and ownership. See my other article for automatic fixperms on cPanel servers: http://boomshadow.net/tech/fixes/fixperms-script/


FastCGI (aka: mod_fcgid or FCGI) is a high performance variation of CGI. It has the security/ownership benefits of suPHP in that PHP scripts will run as the actual cPanel user as opposed to ‘nobody’. The difference with FastCGI is that it can drastically save on CPU performance and give speeds close to that of DSO. It can also be used with an opcode cacher like eAccelerator or APC, which can help further speed the loading of pages.

The drawback is FastCGI has a high memory usage. This is because rather than creating the PHP process each time it is called, like suPHP, it keeps a persistent session open in the background. This is what lets it work with an opcode caching software.

If you like the security/ownership benefits of suPHP and you can afford a major increase in memory usage (meaning you already have a low average memory usage), you may wish to consider using FastCGI.

Comparison Graph

Low CPU usage
Low Memory consumption
Runs PHP as site owner instead of Apache

only w/ suEXEC
Good security

Special Note for WordPress Users

If you are using WordPress to run your site, please consider the following:

  • Functions that require uploading files to the server (such as Auto-updates or Plug-in/Theme installation) will NOT work unless PHP is loaded as a CGI module. This means they will ONLY work with suPHP or FastCGI. This will ensure they are uploaded with the correct ownership & permissions.
  • CMS platforms such as WordPress will notoriously run a high CPU load. You will want to install a caching plug-in such as WP Super Cache, especially if you are running suPHP. If you find that your server is still continually struggling with CPU usage, you may want to consider switching to DSO or FastCGI.

Note about this article

This article is one I originally had written for the ServInt KnowledgeBase. It went through some of their editors and was also featured in their blog. You can find modified versions of this article over on their pages. They are using my article with my permission.

Change Log:

  • 01/09/13 | Rewrote some parts to alleviate confusion

  • 02/12/12 | Added some more definitions

  • 02/02/12 | Link clean up

  • 10/06/11 | Better explanation for CGI with suEXEC

Jacob "Boom Shadow" Tirey

Posts Twitter

A linux web hosting administrator, a professional production sound man, and a renegade cop without nothing left to lose.... Ok, that last part is made up. In all seriousness, my passion in life is to help people; whether that be with help running their sites or with their productions. The name 'Boom Shadow' was given to me by a great group of filmmakers called Star Wipe Films. back in 2005 and has been with me since. I hope my site is helpful to you, and if there's something you need, drop me a line!
  • Peter Briers

    Best intro into the topics I’ve read! Thank you!

  • Paul

    This is exactly the information and comparison I needed, very clearly explained. FastCGI seems to be the way to go for the new server I’m ordering soon. Thank you.

  • All I want to say is THANK YOU SO MUCH for this clear explaination.

  • Pingback: Give Apache Permission To Write To /home/*// Directories | Click & Find Answer !()

  • Brian Coogan

    Really great article, so helpful to see it all so nicely explained.

    Couple of important factual errors which you should update though:

    Under DSO, it says re files created by DSO: “They will not be readable from the web.”. This is a typo; normally they will be readable as they were created with the user that PHP is running as. (Assuming only that the PHP user is the same as the webserver user which is normal).

    Second point, which is a more sophisticated error, is in the second part of the sentence: “If a hacker finds an exploit in your PHP script, they could implement a file that has the same privileges as important system files that are also owned by ‘nobody’.” The reality is that there are intentionally no important system files owned by the “nobody” user. The biggest danger comes from the ability to see database and other passwords used in config files in other accounts, as well as possibly modifying any writable files. In essence, DSO lumps all users under one user-id so anything that can be done by PHP is possible. Obviously this completely screws up security on a multi-user (shared) server!

    Of course, a secondary danger is that, once they have any sort of access to your server, a knowledgeable hacker can often become root unless you’re up to date with patches. The ability to look around your server and run commands allows them to find weaknesses in the system itself as well as exploiting the user accounts.

    Again, thanks for the wonderful article, very readable and I’m sure it will continue to help many people!

  • Thanks so much for sharing this! I hadn’t seen that yet. Very good info to know. I think it’s about time for cPanel to better support mod_ruid2. I need to dive into testing it anyway. This serves as a good excuse.

  • does mod_php/dso spawn a new php process for every request ?

  • What a wonderful comparison these are. You mentioned here each and every things on this comparison that gave huge impacts.

  • Pingback: How to secure Wordpress tips | David Tiong()

  • nobody

    you are the only blogger that speaks to minds of common vps owners. you rocks!

  • You might want to make mention of running PHP as a DSO with mod_ruid2 as well, since you get the speed of DSO, with the security benefits of suPHP. 😉

  • David Bullock

    For DSO’s, you say:  ‘Websites that need to upload files through PHP will run into file permission issues’ … 

    (This is for the sake of argument, to understand your point better).

    If I my Linux/Apache stack was ‘single site’, then this need not apply. Best practice would have me create a non-privileged user and non-privileged group for each and every daemon.  So I define a ‘nobody’ user ‘apacherun’, belonging to a ‘nogroup’ group ‘gapacherun’.  Apache and PHP scripts will run as this user.  In my site’s Apache DocumentRoot, I point to a directory where the files are owned by some other user (‘webintaller’), with a group of ‘gapacherun’.   Some directories, where I want the PHP scripts to be able to modify files (WordPress updates, uploaded pictures, etc), I can make group-writeable, but I don’t have to make them world-writeable.  I’m not obliged to re-use the ‘apachrun’ user or ‘gapacherun’ groups elsewhere on my system.  Thus, I gain the benefits of DSO, while the only drawback is that there is potentially a bunch of files which are vulnerable if an attacker finds out how to upload and then execute the PHP code of their choice.

    What you’re talking about here is a problem only in a ‘shared hosting’ environment, where there are multiple tenants of the Apache server.  To prevent each tenant’s files being vulnerable to attack from  other tenants (malicious or not), you necessarily forego the option of having selected files/directories under the DocumentRoot owned by the group that Apache’s running with.  Thus, the ‘nobody’ user has no write-permission to the 755 directory.

    … right?

  • David Bullock

    I don’t understand how: ‘all files created by a PHP script will have the ownership of ‘nobody’. They will not be readable from the web.’   Surely the web-server can read the file the script wrote?  They are running as the same user!

    • marten

      That is what confused me also in this article. I suppose it’s just a typo, but maybe Jacob can confirm?

  • When I activae SuPHP on my server certain scripts won’t run, plus automatic updates don’t work. It also doesn’t allow me to go to a non wordpress .php page but redirects to the 404 error not found page. CGI and Fast CGI seems to be the only ones working right.

    • It sounds like you have a permissions or ownership problem. Try running this suPHP Permissions/Ownership fix: http://boomshadow.net/tech/fixes/fixperms-script/

      That redirect to a 404 page issue sounds like it might actually be a problem with your .htaccess. Try running that perms fix first. If you still have that 404 redirect issue, let me know.

  • Pingback: Configure .htaccess. to use FastCGI for PHP » Mikey Boldt()

  • Ilja

    Very good 🙂

  • Hosting

    cPanel use by default suPHP, that means the webserver have the same permission of the ownership owner. 
    The problem is that the mails are store with also the sames permissions of the owner, what i’m saying is how hacks the webserver hacks the mail folders. And in my point of view using suPHP in cpanel is a major security risk.

    When the webserver is hacked we can restore to the last backup and I think is a minor security risk (depend the type of site), but when they access to our mails (/home/USER/mail) they can do a lot of damage.

    Don’t you agree?

    My solution is using suPHP but the account must have 2 users/groups: one user have access to all files in home folder and the second user have access only to the webserver folder. The webserver have the same permissions of the webserver folder.


    group_ALL: USER_ALL

    Please give your contribute also in cPanel forum: http://forums.cpanel.net/f185/webserver-user-access-mail-folder-300972.html#post1251792

    • I see your point. In theory, if a user was compromised when the server is running suPHP the perpetrator could read the mail. They won’t be able to send mail, but they could read them.

      Honestly, in the years I’ve been doing this I’ve never seen that come up. Typically, an account is compromised via an FTP password and then the user’s files are manipulated. The things that get inserted are: bank fishing sites, php mail() sending scripts, iframe embeds, redirects to other sites, or simply page replacement. These are generally automated hacks that are blindly done by a bot.

      I’m not saying your concern isn’t valid, I’m saying its probably not that common. I doubt cPanel developers would put a high priority on this.

      If you’re really worried about the mail security via a PHP vulnerability, you should switch your handler to DSO. Files written to the server by Apache would be owned by ‘nobody’ and therefore wouldn’t have access to the user’s mail or etc folder.

  • Pingback: Hosting Glossary | Think Webs Hosting Simple Website Solutions()

  • Pingback: WordPress issues “Can’t write to wp-config.php” | Leigh's Blog()

  • Bonek

    I’m going to run vBulletin 4 forum, can you suggest me what should i use for PHP handlers.
    I’m using  a VPS with 1,5GB ram and single core cpu.

    I’m kinda noob on this. Thanks for the answers

  • Ben

    Hi Jacob, apparently mod_userdir is not compatible with fastcgi so the http://server/~account method of accessing sites does not work. I have trouble using the hosts file method as I think my ISP caches sites and doesn’t refresh very often. Any other suggestions for accessing sites before the domain propagates?

    Thanks 🙂

    • @Ben, yeah If you want to use a mod_userdir, you actually have to disable suEXEC. FCGI will be similar to DSO at that point, but at least you can do basic site tests if you need. You will want to re-enable suEXEC as soon as you can, or else you’ll see errors when trying to do file uploads and such.

      • Ben

        Thanks Jacob, I didn’t realise you could turn off suEXEC temporarily without any effect on the front end. Good to know!

  • Dodong

    it’s really help for a newbie like me…..

  • Mj Zion

    In our WHM it is showing as

    Configured Value

    Default PHP Version (.php files)

    PHP 5 Handler

    PHP 4 Handler


    Apache suEXEC

    Apache Ruid2

    Could you tell me what does this means

    • Hi,

      I don’t understand your question fully, but it means suexec with dynamic php library object is loaded.

      To take advantage of mod_ruid2 , you should simply disable suexec and enable mod_ruid2. That is how we configure our cPanels atm IIRC.

      • Mj Zion

         Thanks for the reply.

        My question is PHP 5 Handler is showing as DSO on my configuration
        and suexec is set to on.

        How both  this works together ?

        In b/w, Thanks for such a great article. Very helpful for beginners like me!

        • Mj Zion

           If the server configuration is PHP dso + suEXEC described as above,  will php run as each account’s username or under user nobody. ?

  • All setups we do now involve DSO + mod_ruid2. We have lots of cPanel and DirectAdmin configured like this and the performance seems to be very good with this setup. You should update the article, since this is a really nice alternative IMHO

  • Pingback: Common WP problems after server migration and how to fix them | Jehzlau Concepts()

  • simple yet most comprehensive article explaining about php handlers. I like your comparison graph which make me easy to understand the whole difference between all of the handlers.
    btw, I have dedicated server with dual cpu (8 cores) and 32GB of RAM intended for shared hosting environment, from your point of view, which handler is best for this purpose? i’m stuck between suPHP and fastCGI :s

    thanks for your advice.


    • Realistically, with that much power, you should virtualize the environment to maximize your hardware.  Otherwise most of those resources you have will be wasted for the most part.

  • Arun

     Nice Explanation  :)… It’s GOOD

    Thank you.

  • Ritesh Sanap

    Sorry for replying Back, i solved that problem by enabling Apache SuEXEC, i have seen the changes in performance, i first kept DSO , it used to take time to load, but FastCGI is best ever i have seen, and you did a nice comparison

    • p, li { white-space: pre-wrap; }

      I’m glad that you got everything working for you 🙂

  • Ritesh Sanap

    Hello, i changed from DSO to FastCGI but still it is not running as a user and running as the nobody

  • Whoa! All I need to know about php handlers are right here! Thanks for the very useful comparison table of the 4 handlers. Now I have decided the fastCGI is the way to go as I’m always maximizing my CPU usage, but I’m only using around 8GB of my 25GB RAM. The file permission are same with suPHP. So switching to fastCGI from suPHP will not be a headache.

    Btw, are there any common problems in changing handlers from suPHP to fastCGI? Like this blah blah blah doesn’t work anymore and it works with suPHP, and that blah blah blah doesn’t work with fastCGI but works well with suPHP? Or I don’t have to worry about such? 😀

    •  @jehzlau:disqus , I’m glad the article was helpful for you. Sounds like you got quite the beefy server there. You are right about the permissions/ownership. suPHP and FastCGI share the same perms set. You can switch between the two handlers all day if you wanted. No need to even run a perms fix.

      As for common problems, I HAVE seen a couple errors when going to FastCGI. If you start to get strange ‘Upload’ errors when doing file uploads through PHP, try increasing the ”
      FcgidMaxRequestLen” limit for FastCGI. You would make the change to the post virtual global conf.

      If you start to get ‘500 errors/read data timeout’ errors, you should increase the timeouts for FastCGI via the post global include file.

      I’ll probably put out a separate article about FastCGI errors.

      • Ohhhhh… That’s why. When I changed my handler to fastCGI from suPHP, all of my sites encountered “500 Internal Server Error”. I just reverted it to suPHP because I don’t know how to fix it. Hahaha!

        Where I can find that post global include file? O__O

        • On a cPanel box, you will want to edit the post_virtualhost_global.conf. You can modify that through WHM using the ‘Include Editor’.

          However, 500 errors are a different matter. It sounds like you may have some improper coding in an .htaccess file. Try renaming some of the affected sites’ .htaccess files so that they aren’t executed. This will narrow down if it is the problem. I would venture to guess that you may have  a suPHP specific command in there. Such as: SuPHP_ConfigPath

          • Oh thanks! But I think renaming the affected sites’ .htaccess would be time consuming as I have around 900+ wordpress sites in my dedicated server. The .htaccess contains only mod rewrite rules of the custom permalink feature by WP. 

            Geezz.. so it’s really hard if I encounter 500 errors after switching to fcgi. O__O

          • Troubleshooting for that many sites can be difficult. However, whatever is affecting one, is most likely also the cause for the rest of the sites. I would say try moving the .htacess on one of them to see if you can fix it. If that works, look at the code inside the file to see what particular caused the issue.

          •  I hope you’re running maldet, because WP sites are notorious for being hacked, and with that many, I’m sure it’s difficult to keep up with finding sites that have been hacked in your environment. . .

  • Sdancer75

    Thank you for your article. What exactly DSO and the other acronyms means ?


    •  @d4a7174cec94babe212ad9ecce53fa27:disqus
      DSO stands for: Dynamic Shared Object
      CGI stands for: Common Gateway Interface
      suPHP stands for: Single User PHP
      FCGI stands for: FastCGI. Its meant to be a faster variation of the CGI handler
      suEXEC, I believe, stands for: Single user executable. You can find more information here: http://en.wikipedia.org/wiki/SuEXEC

  • Alex

     Thanks 🙂    

  • This my friend is an *EXCELLENT* article about the uses of DSO vs. FCGI vs. CGI vs. SuPHP.  I’ve been reading this and I have to say it’s SUPER informative! =0)

  • While there are distinct disadvantages to using DSO, the core disadvantages are actually not so much about ownership of created files.  More importantly, the major disadvantage is that when running under DSO all PHP scripts must be readable by the “nobody” user.  This means that it’s possible for one account to lookup the database username and password of any accounts on the system where they can guess the location of config.php files, though they may have to bypass PHP limits first.  From there, those accounts and your server will be compromised one way or another – remembering users often use cPanel passwords for database passwords!  Surprisingly this is rarely discussed or explained clearly.

    A second disadvantage is that the “nobody” user, which your PHP scripts run under, cannot create files unless the folder is writable (ie 777).  This means that any user can place files in, or delete them from, that folder, and without suphp or phpsuexec (or fastcgi) or .htaccess directives, they may then be able to run these files to take over the account.

    The advantages of DSO are that it is many times faster than suphp.  The reason for this is that suphp starts up a separate PHP instance (binary) for each web access.  It’s worth noting here that fastcgi is pretty good and gives the same security levels without running a separate PHP instance for each web access (see great points in article).  The other advantage is that it’s harder for a hacker to change a web account’s normal PHP files, as they are owned by a different user.  This is actually a real advantage when there are only a few secure and well-maintained accounts on a server.

    Thanks for the great article!

  • dankfresh

    Short and simple.  Great article.  If only PLESK offered the same flexibility to change handlers as cPanel did…. 

    •  @6179c71a5b39683a48c23550cff2fc02:disqus , I agree. Most all of the articles on my site are written solely for cPanel servers. Its simply that I prefer it. It has quite a few benefits over Plesk.

  • Ben

    Thank you for this excellent explanation of PHP Handlers. I currently host a number of WP and other CMS based sites so use suPHP but am constantly suffering from performance issues. FastCGI sounds like the way to go. Are there any guidelines to work out how much memory might be required under FastCGI? Do you think a Servint Ultimate VPS (3GB guaranteed, 6GB burst RAM) would be up to the job? Is there any preference for eAccelerator or APC (or can they co-exist)? Thanks in advance.

    • @4eea8e0a14a44ba082190cafe72d3f93:disqus , I’m gad the article helped you. Unfortunately, anticipating the memory usage that FastCGI will consume is not an exact formula. Assuming that keeping the sites up and running is critical, I personally, would look at your current average usage and try to leave open triple or quadruple that, just to be safe. If this is a development server, I’d say just make the switch to see what happens. You’ll get a real number at that point.

      eAccelerator and APC both have their place out there. Having both wouldn’t do any good. It offers no advantage to try to cache the same information twice.  This benchmark link can provide some useful info in helping you choose: http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html  I’ve found that APC is rather easy to setup and does a great job. It certainly is being actively maintained/updated. That and I’ve seen less issues with APC.

      As for a ServInt VPS, the Ultimate is certainly a powerful system and can handle a large number of the hosting needs out there. But whether it (or any package from any provider) is enough for you depends on other factors such as bandwidth, hits, etc… If you really want a good assessment, I would say hit up my buddy Dan Kobel, in Sales. The Sales team is really great at helping evaluate what one’s needs are. I promise its a no-pressure talk. They’re just happy to make a recommendation. Hit him up: dkobel@servint.net

  • Anonymous


  • chownsauce

    DSO (mod_php) does not have low memory consumption. That is incorrect.

  • Vipin Garg12

    Hi, Good link and good information.  I like it,

  • Anonymous

    Good quick and dirty intro; thanks.  But now I’m curious, have you encountered mod_ruid2 before?  It seems fairly new, but I’m hearing good things.  Also this chap suggests suPHP+Varnish is a viable option: http://blog.unixy.net/2011/02/opcode-caching-suphp-cpanel-best-workaround/  Your take?

    • Zzzzzzzzzzzzzzz


  • Wow thanks! I’m using one of your competitors that severely restrict RAM usage. To improve performance, I had all my WordPress sites using FastCGI and Google’s Page Speed module turned on. But due to the aggressive RAm constrictions, I was getting a lot of 404/500 errors that way. Thanks to your comparison, I now realise that FastCGI is good for everything that consumes little memory, giving a huge performance increase in exchange of using more RAM. On RAM-constricted servers, I realise now that CGI is a safer choice. Well, I can always accelerate WordPress with cache plugins (like W3 Total Cache) and externally doing further caching with Cloudflare. That way, the backoffice might be slower (more CPU usage!) but at least I keep the WP processes fitting neatly in the tiny RAM slots.

    You were a life saver! Thank you once again!

    • Glad it was helpful to you. Though I don’t sell any hosting of my own, so no worries about competition. I’m just here to help folks out! I’m glad you were able to find a setup that suited your needs.

  • Really helpful article. Thank you so much…

  • Sarah

    I asked My hosting support to set up fastcgi and 1 blog with 300 unique visits Per. Day is eating 1gb RAM. At least 1 restart Per. Day.

    Im lost

    • Daedalon

      It sounds there is something wrong with the blog or the hosting environment. 300 visits per day shouldn’t take much RAM. Suphp consumes less RAM than FastCGI. You might want to consider changing. Before that it’s good to try to optimize your blog or use an OpCode cache like APC. For optimizing the blog check that you’re not running any scripts or plugins that cause the problem, and when that’s done, setup caching by your blog options or by a separate plugin.

  • Pingback: php handler ……….??? « Blackstreetnight's Blog()

  • Awesome article! Now I understand the differences between each of them. Thank you!

  • I have just been told by my host that “DSO based PHP will kill your performance hard right there alone and opens massive security holes” Sometimes I don’t trust the help I get from my host as each person has a different outlook and I feel there’s some inexperience there also. The first line on the most recent help on this I received is “Some moron has apparently changed you over to “DSO” based PHP — BAD, VERY BAD!” 🙁
    I’ve been reading up all over the net to get help in the decision to change. Your post has helped a lot to shine a light you might say, but I’m still not sure which way to turn. My server is a VPS with multiple accounts (all mine) so if there’s any issues with changing it only effects me.

  • I have just been told by my host that “DSO based PHP will kill your performance hard right there alone and opens massive security holes” Sometimes I don’t trust the help I get from my host as each person has a different outlook and I feel there’s some inexperience there also. The first line on the most recent help on this I received is “Some moron has apparently changed you over to “DSO” based PHP — BAD, VERY BAD!” 🙁
    I’ve been reading up all over the net to get help in the decision to change. Your post has helped a lot to shine a light you might say, but I’m still not sure which way to turn. My server is a VPS with multiple accounts (all mine) so if there’s any issues with changing it only effects me.

    • @facebook-100002256352862:disqus , that is true that you could ask 2 different people and get 2 different answers on most things. However, I can tell you that my findings here are based on actual usage on many servers over the last few years. Also, at the 2 hosting companies I have worked for, all the advanced techs found the same to be true.

      DSO is accepted to actually be the most efficient handler for performance. I don’t know why they told you it would kill it. As for the security holes, that part is arguable. With DSO, a hacker’s script could have write access to files outside of the user account. This would be a very very bad thing if you are hosting other person’s accounts (such as re-selling). You do not one use affecting the others. suPHP will prevent that.

      However, if all the accounts are yours, then it would not be as big of a deal if one account affected the other. Most hacks will affect only certain folders and files. It actually could be easy to fix. For a lot of single users that are NOT reselling, the speed benefits of DSO outweigh the risk.

  • Hi, i just made a move to a a dedicated server and struggling with higher CPU loads. My php 5 handler is suPHP. I also just installed xCache but you said it would have not effect with suPHP. I was considering making a switch to DSO… Is Apache suEXEC needs to on if i make a switch to DSO? Do you think DSO would be a safe on a dedicated server? Also can i revert back to suPHP without any issues?

    Thanks for the wonderfully informative article!


    • @facebook-100001135869311:disqus , suPHP is more CPU intensive. DSO is the most efficient and as such, it is actually the default handler used on new servers at a lot of hosting companies. You should be safe to switch. You’ll simply need to update the permissions if you get any errors on your site.

      suEXEC is not necessarily needed for DSO. However, I usually see it enabled on default. And for good reason; it adds some security advantages.

      You can certainly revert back to suPHP. Switching between handlers is always possible, you need to be aware that it may cause some permissions/ownership issues. You’ll have to go through your files and set permissions as is needed by your software.

      Just keep in mind, when you make the switch, be prepared to test the sites and update individual file permissions whenever you see errors.

  • Pingback: HiddenTao › Ubuntu 10.04 Lucid 64-bit + PHP 5.2 FastCGI + APC + nginx()

  • Thanks for the article. Helped me understand what was wrong with my WordPress plugin updates and permalinks.

  • Tristan

    Awesome explanation, thanks 🙂

  • John

    Wow that’s a great explanation!
    Still seems like wordpress is a bit of a pig.

    • @cb83fe7c416841345b525f28edeb3b29:disqus  , It certainly can be a resource hog. Though, you can’t blame it fully on WordPress. Its got so many cool plugins and themes. Its like a new computer or iPhone. You start installing all those fun programs and apps, and it bogs down 🙁

      Also, as with any site, the trick is  all in the configuration. It really depends on how well you set up the server to meet your requirements. Which is where the PHP handler comes into play. It can make all the difference in the world. I’ve seen sites go from bringing a server to it’s knees, to running minimal resources all as a result of changing the handler. Combine that with say, something like a cacher or mod_deflate, depending on your needs, and you can certainly handle more.

  • PS: I also still have eAccellerator on my server. You said that it doesn’t work with suPHP, so I’m wondering what it’s doing there now. Should I uninstall it?

    • @twitter-19589573:disqus , yeah. OPcachers like eAccelerator won’t work with suPHP. Go ahead and un-install eAccelerator because its not going to do anything.

      • Sorry to spam your comments with 2 threads. Anyway if I choose to switch to FastCGI as seen in the thread below, should I then keep eAccelerator?

        •  @twitter-19589573:disqus , yeah. If you make the switch, FastCGI works really well in conjunction with OPCachers like eAccelerator. Definitely keep it then.

  • Hey thanks for explaining this in detail. I have recently switched from DSO to suPHP and it’s killing my load. I’m tempted to switch to FastCGI after reading your article but I’d like to first have a little clue on how much more memory is more? Is there a way to calculate that? I can give you numbers if you can help me (unique visits per day, my server specs, etc.)

    Thanks in advance! 🙂

    • @twitter-19589573:disqus , If its killing your load, FastCGI might be better for you. Then you can use an OPcache again.

      There really isn’t a way to calculate how much more memory it will use up. But you can try to gauge it to see if you have enough headroom.

      For instance, if you’re memory usage is at 75% of your limit already, you’re likely going to go over when you switch. If you’re only using up 30%, you’ll probably be good.

      Honestly, you’ll just have to try it and see. Make sure you’re in the server with SSH when you make the switch. Watch the memory. If it starts getting to the threshold, you’ll know to switch it back.

      •  Thanks for responding so quick! 🙂 You know I actually have 4GB memory and I’m only using about 400MB so that’s 10%. According to your calculation I should be in good shape switching to FastCGI, correct? Is there anything else I need to know before switching? Do I just switch it in WHM and that’s it, or are there other things I need to do as well?

        • @twitter-19589573:disqus , I’m glad I could help 🙂

          It does, indeed, sound like you have plenty of headroom. FastCGI sounds like it could be the better solution for you.

          The main thing to be aware of when switching handlers is the ownership
          and permissions of your files; make sure they’ll still be able to
          execute properly. However, FastCGI and suPHP share the same set of
          permissions. If your site works properly on suPHP, it will work properly
          with FastCGI.

          The switch is easy, and all you have to do is change it in WHM. FastCGI
          is not normally a default option in WHM, so you may have to run an
          EasyApache to get it.

          • Thank Jacob, I wish you were my host support LOL. I’m setup with FastCGI now and everything works great. Just need to ask my host to reinstall eAccelerator for me. Cheers!

          • @twitter-19589573:disqus  , No problem. Glad to be of assistance! Also, I have a sneaking suspicion that I AM your host support. Does the name ServInt mean anything to you?

          •  woah freaky!! but cool at the same time. how come you’re way nicer here than on the portal? :p

          • @twitter-19589573:disqus , LOL! I hadn’t noticed. I usually try to be very nice. The only thing I could perhaps say is, it’s work. You know how that goes. Bad days on occasion and what not. Though people usually comment how nice I am. Heh heh.

  • This was an EXCELLENT article. Kudos to you. I live in the design world and while I don’t need (or want) to dive deep into learning backend setups, it really helps to have a conceptual understanding. Thank you for this article – much appreciated.

    • Glad I could help John. I wrote this specifically for designers who resell or others who have a VPS but are not very tech savy. Not everyone can afford their own system administrator, so they rely on their hosting provider for answers.

      A hosting provider doesn’t always have the time to really educate their customers. They can answer a question or simply TELL you which handler to use. But it really helps to understand the mechanics behind it. Plus its not that hard once someone explains it once.

      I hope this will save people a lot of confusion. Let me know if there is ever a topic you’d like to see up here on this site.

  • Pingback: 500 internal server errors with SSL « Rage on Omnipotent()

  • Colin

    Two quick corrections I can think of for this article:

    1) You can auto-update/install plugins, etc. with DSO as the API. You just have to be very savvy with the permissions to make all the necessary files and folders writable by the websever (this doesn’t mean 777, which you should never use unless you like getting hacked)

    2) suPHP/FastCGI isn’t really ‘more secure’ than DSO, it is just a different type of security. What I mean is, if your site gets compromised in suPHP, then the hacker has access to any file owned and writable by the user, such as your entire home directory on a cpanel account. Whereas in DSO, they would only have access to any file on the server that is writable by the webserver as opposed to the user. This means that with DSO the hack can span multiple user account’s home directories but only affect certain files, with suPHP the hack will span the entire affected account but pretty much only that account. So if your server only has one account on it, then the DSO is actually more secure than suPHP.

    • Carlos

      Hi, can you be specific in relation to the permissions which would work with DSO for the WP auto-update? Thanks!

  • hi,
    liked your nice writing. in short you’ve explained a lots of features. but i am confused with the comparison chart. what the ‘x’ means? does it means feature has or has not! however, reading the above article it seemed to means ‘feature has’! isn’t a tick mark will be better, at least not confusing!

    • Thanks for the compliment. Also, I could see how one could get confused with the graph. I had originally written this up on my MediaWiki site, and that was the easiest way to mark a table.

      I’ve changed the X’s to check marks. It looks much better now. Thanks for pointing that out!