Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
PHP Programming Software Apache

Optimize PHP and Accelerate Apache 191

Posted by CmdrTaco from the wouldn't-it-be-nice-if-we-were-faster dept.
An anonymous reader writes "As the load on an application increases, the bottlenecks in the underlying infrastructure become more apparent in the form of slow response to user requests. This article discusses many of the server configuration items that can make or break an application's performance and focuses on steps you can take to optimize Apache and PHP."
This discussion has been archived. No new comments can be posted.

Optimize PHP and Accelerate Apache More

Optimize PHP and Accelerate Apache

Comments Filter:

  • want performance from php? (Score:3, Interesting)

    by wwmedia ( 950346 ) on Sunday May 27, 2007 @10:40AM (#19291899)
    want performance from php?

    Dump Apache! its the slowest link!

    use Lighttpd [lighttpd.net] + latest PHP 5.2.2 + APC [php.net]

    • Re:want performance from php? (Score:4, Interesting)

      by Ant P. ( 974313 ) on Sunday May 27, 2007 @10:49AM (#19291949)
      I'll second that - Apache is as bad as Firefox when it comes to resource waste. On my machine, lighttpd uses about 1MB of RAM, not counting the PHP processes.

    • Re: (Score:3, Interesting)

      by Anonymous Coward
      There are many reasons Apache httpd is the standard and speed isn't one of them but lighttpd is pretty awful although lua integration is cool (much faster than PHP). I might say that if you want performance, avoid crap like PHP and Ruby. That's pretty much true but ignores the fact the bottleneck is usually going to be the database, regardless of whatever other software you happen to be running.

      TFA reads like a newbies blog article, 'OMG I know how to haX0r php.ini and httpd.conf'. Any half decent sys admin

    • Re: (Score:3, Informative)

      by Anonymous Coward
      That sounds like a rather dumb comment. I also bet you are comparing lighty to apache 1.3. Or you do not know what you`re talking about. I have had (until february) a P3-400 w. 256 MB with around 200 Domains configured (of which 2 make up for 98% of traffic)
      running a LAMP Stack w. apache 1.3. The machine serves 6 concurrent users with 8.9 Database-Hits/Sec serving around 30-40G/month.

      I have absolutely no problem with apaches speed when it comes to serving pages. It does lag when forking processes, though, s

      • Reverse proxy (Score:3, Informative)

        by Snowhare ( 263311 )

        And get a reverse proxy (apache2.2).
        I have to second this point. I am in the process of setting up a new site that needs to use a PHP based knowledgebase system. The raw performance numbers of the knowledgebase were absolutely abysmal (6 pages/second). I spent half a day working with the Apache 2.2 reverse proxy and got it up to 350 pages/second.
      • Just so you know, you can make processes die after X requests to solve the memory problem.

    • Re: (Score:3, Informative)

      by malsdavis ( 542216 )
      I would love to dump Apache, but Lighttpd and the other alternatives simply don't provide the power, functionality and customisation I need from my servers. Then there are the many inequitable Apache extensions which are simply a necessity in some situations.

      Personally I feel Lighttpd is just too light, but I agree, Apache is too heavy. I would love to find a happy medium but I am yet to find a httpd server which even approaches Apache and its popularity shows that an awful lot of people agree with this.

      • Re: (Score:3, Interesting)

        by TheLink ( 130905 )
        lighttpd leaks memory, how secure and "lightweight" is that?

        So far Apache is good enough for me, but if you're going to replace Apache with something that is fast and has features, you may wish try Zeus.

        Anyway, I'd dump PHP first. PHP is slow and has tons of security problems - and judging from the way the devs do stuff, there'll be plenty more to come.

        • Re: (Score:3)

          by TheLink ( 130905 )
          Flamebait? Someone can't handle the truth? Tsk tsk :).

          "lighttpd leaks memory":
          http://www.google.com/search?hl=en&safe=off&q=+sit e:trac.lighttpd.net+lighttpd+memory+leak [google.com]
          Random complainer: http://hostingfu.com/article/nginx-vs-lighttpd-for -a-small-vps [hostingfu.com]

          As for security: Apache isn't what you'd call secure software, but Lighttpd isn't either.

          PHP is slower than Perl or Python for most stuff. This should be common knowledge amongst decent programmers- go find/make your own benchmarks and links.

          PHP securit

          • Re:want performance from php? (Score:5, Insightful)

            by malsdavis ( 542216 ) on Sunday May 27, 2007 @01:18PM (#19292999)
            "PHP is slower than Perl or Python for most stuff."

            I'd say that in practice (i.e. when performing the vast majority of dynamic web functionality: e.g. database lookups) the opposite is true. Perl & Python are quicker at some tasks, but every-time I've rewritten a website between PHP and Perl (I don't program in Python because it's named after my most hated animal), PHP has come out slightly on top.
            • So, Indy, you gave up on archaeology and fighting Nazis to hack PHP and Perl?
          • Flamebait? Someone can't handle the truth? Tsk tsk :).
            Or not all have mem leaks and/or don't care for bugs closed months ago.

            PHP is slower than Perl or Python for most stuff.
            And your filesystem, database or network is even slower. Benchmarks != real applications.

            PHP security? ;). Need I say more?
            Maybe show security problems on Flickr or in Yahoo apps or comparable apps written in PHP.

      • Personally I feel Lighttpd is just too light, but I agree, Apache is too heavy. I would love to find a happy medium but I am yet to find a httpd server which even approaches Apache and its popularity shows that an awful lot of people agree with this.

        Exactly my feeling. I've settled with a frontend Apache, running an event MPM, along with a backend apache with a prefork MPM. The frontend handles URL-rewriting, keepalive connections and mod_deflate filtering, then serves all static content. Non-static co

    • But I Can't Pronounce "LLMP"! (n/t) (Score:4, Funny)

      by Mateo_LeFou ( 859634 ) on Sunday May 27, 2007 @11:19AM (#19292143) Homepage
      no text

    • Re: (Score:2, Insightful)

      by pooh666 ( 624584 )
      Apache is what you *make* of it. If it is heavy look to your sysadmin and cut out the stuff you don't use. The idea that Apache is a bottleneck compared to ANY scripting application is totally misguided nonsense. I can't believe such an ignorant comment got any mod points, even on Slashdot. I can get at least 100Mbs out of a single server pumping out static content with nothing special other than removing unused modules in the compile to save on memory. So guess what, you are WRONG.. I at one point tried

    • Re:want performance from php? (Score:5, Informative)

      by doubledjd ( 1043210 ) on Sunday May 27, 2007 @12:33PM (#19292665) Homepage
      My history is java but I've come to appreciate php recently. The track record on it when used properly is impressive. In case there are some people just starting with it, the several of the problems with php performance is caching. (this is pretty standard stuff so apoligies to people who know a lot more about it than I do)
      1. Use apc or eaccelerator. (yahoo uses apc so that is the one we went with). This alone will give considerable benefit. Apc can defaultly cache any of the php that runs or it can also be used as a local cache for objects you'd like to store programmatically.
      2. If you need distributed items, especially in a non-sticky load balanced environment, look at memcached.
      3. Use a query cache for your db
      4. If your db connections are expensive, look at sqlrelay
      5. Look at whether a caching proxy is a possibility for you (squid or apache has some mods).
      6. Benchmark your pages and functions. It is the only way to know if configuration tweaks are adding any value. I usually do this after a full profiling using apd (to help identify the bottlenecks and frequently called functions). I usually run apache's ab to get a look at page benchmarks.
      7. you can always write c extensions for items in php that are too slow. Of course, you'll have to know c, increased maintenance, development time, etc
      There are a million things to be done to increase performance. Obviously, don't use anything blindly. Still, I think the opcode cache (apc or eAccelerator) is probably the easiest and most substantial win.

      • Re: (Score:2)

        by rsax ( 603351 )
        "If your db connections are expensive, look at sqlrelay"

        To what extent have you used sqlrelay? Any particular shortcomings? It sounds like it would be a nice solution to use where you have multiple database servers and only want to use one for updates/inserts but not a lot of people use it for some reason.

    • Re:want performance from php? (Score:5, Informative)

      by consumer ( 9588 ) on Sunday May 27, 2007 @12:45PM (#19292767)

      All that apache does when serving PHP requests with mod_php is run the early phases (auth, URL mapping) and pass the request to PHP. Do you really think that Lighttpd + FastCGI is going to be significantly faster than that? The bottleneck is your PHP code, not the web server.



      Lighttpd is probably faster at serving static content. Most sites don't have enough bandwidth to find out.

      • Re: (Score:2, Insightful)

        by Fweeky ( 41046 )
        Quite; you can easily use FastCGI with Apache too (though lighttpd's built-in load balancing sounds nice; hopefully mod_proxy{,_balancer} will one day grow useful FastCGI support). Do that and watch as Apache sits using about 1000x less CPU than your backend PHP's.

        lighttpd and friends are generally better if you're serving static content, but it's doubtful you'll notice unless you're talking in terms of many thousands of requests per second to a single server. That's not to say there aren't other reasons

      • Re:want performance from php? (Score:5, Insightful)

        by SQL Error ( 16383 ) on Sunday May 27, 2007 @02:38PM (#19293555)
        The problem is not that Apache is slow, it's that it uses huge amounts of memory. If your database is running slow for some reason - say, during backups - requests will start to queue up, Apache will start more and more threads to handle those requests, and things will spiral rapidly out of control.

        Lightppd doesn't have that problem.

        • Re: (Score:2)

          by kbahey ( 102895 )
          If you want to stay with Apache, then the quickest fix for this is to reduce the number of MaxClients [2bits.com] so that an incoming avalanche of traffic does not cause overuse of memory and hence the swapping to hell syndrome.

          What number to set it to depends on the size of each Apache process, and how much memory you can spare in the system.
          • Yes, that stops it killing your server, and instead it rejects requests. It does nothing to actually fix the problem.
            • Your server is going to choke at some maximum number of clients anyway. You might as well configure it to handle what it can and gracefully reject the rest instead of letting everybody's requests wallow in a mire of thrashing.

            • Re: (Score:2)

              by trawg ( 308495 )

              Yes, that stops it killing your server, and instead it rejects requests. It does nothing to actually fix the problem.
              It doesn't actually rejects them (unless you configure it to do so) - by default it just queues them somehow internally in apache (so when one of the clients disconnects freeing up a connection, one of the queued connections waiting for a free spot nabs it).

              I assume this behaviour is documented somewhere, but I haven't seen it.
              • I don't think apache queue the requests. But the operation system does as part of the normal tcp/ip handling.

                The os will always queue incomming requests for a given port if a program(apache) have been bound to that port.
                The request will then be in queue until apache calls accept() and accept the new connection.
                There is ofcause a limit to how much the os will queue, and after that it just refuse new connections similary to if no webserver were running.

                • Re: (Score:2)

                  by trawg ( 308495 )
                  Ahh, ok - I just figured it was apache because I assumed it would have closed the port or something when it had hit MaxClients, so I thought it was dealing with it by leaving the port open and accepting requests and just processing them later on a first come first serve basis, but what you're saying makes sense.

                  So I guess what could also happen is you could exhaust the operating system's ability to handle connections, right? So if you hit MaxClients early and you have thousands and thousands of users trying

                • Re: (Score:2, Insightful)

                  by Rudd-O ( 20139 )
                  Yes, it queues request, and you can configure the queue depth in the Apache config file. See the apache docs.
                  • If you talk about the ListenBacklog option (http://httpd.apache.org/docs/2.2/mod/mpm_common.h tml) it just set the backlog(queue) size for the tcp/ip stack.

                    And just because I am bored now, I looked op SOMAXCONN which is defined to 128, so the default limit for linux(Fedora core 5, kernel 2.6.20) is 128 which is actuelly rather small.

        • Re:want performance from php? (Score:5, Interesting)

          by consumer ( 9588 ) on Sunday May 27, 2007 @03:26PM (#19293879)
          If you use separate processes for your static content and your PHP (either Apache with FastCGI or a reverse proxy), you won't have problems with memory. The size of an Apache process that's just serving static stuff is tiny. It's the PHP processes that take the RAM, and they will do the same when run from Lighttpd.

          • Re: (Score:2)

            by ceeam ( 39911 )
            First - you don't want to use Apache with FastCGI with PHP. And if you use mod_php (like all people do) you can't limit PHP processes to reasonable amount (say, 4 times the number of cores you have) without limiting the number of HTTP requests at all. Am I right?

        • The problem is not that Apache is slow, it's that it uses huge amounts of memory. If your database is running slow for some reason - say, during backups - requests will start to queue up, Apache will start more and more threads to handle those requests, and things will spiral rapidly out of control.
          Don't set MaxClients so high that you'll run out of memory. Apache can queue requests at the ip stack level, before launching a new process to handle them.
    • The reason why Lighty and Litespeed have pulled better numbers than Apache is because they are threaded and use FastCGI, and always get compared to Apache with the prefork MPM using mod_php.

      The latest performance numbers show that Apache 2.2 w/ worker MPM (threaded) + FastCGI can keep pace with Lighty and LiteSpeed. Many of us large site maintainers prefer Apache's feature set.

      I agree that APC rocks, it outpaces Eaccelerator in a big way, and is more stable.

      This article is not worth the read, I could conde

    • Re: (Score:2)

      by kbahey ( 102895 )
      As far as Lighttpd is concerned, there is an up and coming competitor called nginx [nginx.net] (Engine X). Its reputation is that it has all the benefits of Lighty, minus the memory leaks.

      I have benchmarked [2bits.com] APC vs. eAccelerator [eaccelerator.net] and found that eAccelerator is some 13% faster. It also has significantly lower memory consumption than APC.

    • Re: (Score:2)

      by FST777 ( 913657 )
      True, for webpages. But the summary (haven't read TFA yet) talks about applications. Now that's more than webpages.

      Consider a chat-application (I've written and I'm maintaining one) based on AJAX. To feel responsive, every parttaker in a chatsession should at least fire one XMLHttpRequest each second. More would be nice. Lighttpd can handle that with two or three "chatters" online. More becomes painstaking. The same is true with Apache 2 using the default settings, but you can increase the maximum it can

    • The real way to improve server performance... (Score:5, Funny)

      by dgym ( 584252 ) on Sunday May 27, 2007 @09:22PM (#19296285)
      ...is to decrease load on the server. Most of the work can be done on the client anyway, so that is where it belongs.

      Here are a few tips:
      • Databases can get pretty slow with complicated queries, so upload your database to the client when they load the page and then your database queries are distributed.
      • PHP isn't very fast, and neither are Perl or Python, so you don't want to be running them on the server either. Write an interpreter for the language of your choice in Javascript and move your business logic to the client. This will also interface better with the client side database copy.
      • SSL is a performance killer, don't use it. If you need to send something securely just prefix it with a predetermined number of random letters and numbers, no one will think to look beyond them.
      • Writing to databases can be pretty bad too. Try discarding all your changes, your users might not notice the difference, but they will appreciate the performance gain.
      • Even with all the above you might still be getting too many requests. Try designing your site to exploit bugs in the major browsers and reconfigure your users machine to store and load everything itself.
      • Get better hardware.
      • Make your site less interesting, or less reliable. Changing your DNS entry to point to an unrelated site for one week a month can really help reduce load.
      • If you have had success with the other steps then you don't need a dynamic server anymore, code a simple static server in assembly, preferably for the architecture you intend to be running on, and be done with it.

      Best of luck!
    • "want performance from php?

        Dump Apache! its the slowest link!"

      Then dump php, and get a real webapp tool.

  • Of course! (Score:5, Funny)

    by BabaYama ( 899483 ) on Sunday May 27, 2007 @11:13AM (#19292089) Homepage
    You should compile it yourself wicked fast compiler optimizations on top of your wicked fast install of Gentoo (which you also compiled yourself)

    • Hey! I didnt apply stupid CFLAGs. ;)

      Yeah one of the servers on a large site I manage runs Gentoo which I installed.
      Its a smaller server than the others but it can keep up well.

  • Modules (Score:2, Interesting)

    by deftcoder ( 1090261 )
    Apache generally ships (on most distros) with TONS of modules enabled... kill off any unneeded modules (come on, how many of you actually use mod_userdir or mod_rewrite?), tweak your MPM settings, and be done with it.

    I also force PHP to run in FastCGI mode, that way I can use suExec with it to prevent exploits in PHP itself from allowing the entire system to be compromised. Apache suid()s itself after handling the request, but the Apache user can generally write to a few good places, therefore I use suExec.

    • "kill off any unneeded modules (come on, how many of you actually use mod_userdir or mod_rewrite"

      Are you kidding? If anything, those are the two that are the handiest. Ever use short urls? That's mod_rewrite for you. Ever have users with their own public_html? That's mod_userdir.

      Really, if you're going to pick on something, pick on, um, maybe mod_speling. (no that's not a spelling mistake - its a module that tries to guess what you really wanted if you misspelled a url, rather than just sending a 404,

  • Dunmp then both (Score:2, Interesting)

    by butlerdi ( 705651 )
    I have found that a truly scaleable design pattern is using a lean little engine like Jetty and a declarative/Rest based architecture. We have recently ported Sugar CRM PHP/Apache to NetKernel and lost over 95% of the code and subsecond response times. We kept the horrible database design and the workflow in the first version as well, so reworking that will further improve performance and further reduce the need for code. For me performance is important but maintainability is equal. The less code the easier

    • Re: (Score:3, Funny)

      by gbjbaanb ( 229885 )
      If I took an app, "lost" 95% of the code, then I guarantee it'd work faster. Of course, by "work" I mean, "do nothing" but lets not let a little semantics get in that way of some technical self-aggrandisement. :)

      • Re: (Score:2, Insightful)

        by butlerdi ( 705651 )
        Well, it now has all of the original functionality it had and that is down to the lack of redundant code and frameworks. Declarative based systems are just different. PHP is an awful lot of code. The code seems to me difficult to maintain and modify, but this is just my experience. I stopped using the J2EE frameworks for the same reason. After 30 years of hacking this stuff I have seen an awful lot of 3GL, 4GL .... and other frameworks and they all have to me seemed a bit bulky. Like when I try to find the
    • Hey, I'm interested ^^

      Besides that white paper do you have more info about it ?

  • Diet article (Score:5, Informative)

    by billcopc ( 196330 ) <vrillco@yahoo.com> on Sunday May 27, 2007 @11:30AM (#19292209) Homepage
    Maybe I'm being a cynical bastard again, but that article is REEEALLY light on content. Compared to the other featured articles from IBM, which are usually very rich and informative, this one is more like an "idiots guide to apache", the kind that belongs on Digg's mountain of filth. This is little more than a rehash of the Readme files for Apache and PHP combined. It's about as deep as telling a windows user how to make their PC faster by changing to the Windows NT theme. Of much greater value to web professionals is this article from a fellow OSDN site (!) Lighttpd can lighten Apache's load [linux.com]

    • Re: (Score:2)

      by mangu ( 126918 )
      Maybe I'm being a cynical bastard again,

      Well, yes, I agree, you are being a cynical bastard. I just forwarded the link to a couple of people I know who could get some useful tips from that article. You see, not everyone is born knowing it all, some people can profit from stuff that others already know.

      And also, information isn't like money, that you want as much as possible. There is such a thing as information overload, information is something that you want exactly as much as you need, not a bit more. Al

    • Re: (Score:2)

      by hachete ( 473378 )
      what's lighty like with mysql in the mix - I run a LAMP installation which could go faster ... an article on fine-tuning LAMP installations would be useful :-)

      • Re: (Score:2, Informative)

        by Ythan ( 525808 )
        If you want to improve the performance of your database, you should check out Sphinx [sphinxsearch.com] to handle your fulltext searching. In my opinion this is one of the most criminally overlooked pieces of software when it comes to website optimization.
    • Didn't you notice the "anonymous" article submitter? It went like this: someone wanted to know the best way to increase his apache/php speed. Of course he could write an 'Ask slashdot' entry with this question, but would know that he would only get "don't use php" answers. So he had a cunning plan! Instead he wrote this mock-up article, posted it to slashdot, and is now reading the pretty useful comments out here! This is analogous to the way to get help from linux experts. Never ask them directly for the a

  • http is the problem (Score:5, Funny)

    by larry bagina ( 561269 ) on Sunday May 27, 2007 @11:38AM (#19292273) Journal
    Last year, we dumped apache (and http altogether) and went with a gopherd/fastcgi approach for serving up our php pages. For people still stuck on port 80, we have a squid proxy which converts the request to gopher. Since then, traffic has increased 34%, while average load has dropped by 20%.

  • Apache ain't the fastest... (Score:4, Informative)

    by Anonymous Coward on Sunday May 27, 2007 @12:29PM (#19292643)
    It's common knowledge that Apache certainly isn't the fastest out there to server web pages. For static pages lighttpd and, heck, even a basic stand-alone Tomcat (yup, a Java server!) can easily serve as many pages as Apache. That was already the case for, say, Java 1.5 / Tomcat 5.5. Now take Java 1.6 and Tomcat 6 (or, better, Resin [not completely free]) and suddenly Apache is looking even more ridiculous.

    For anything SSL related IIS makes fun of Apache.

    For many concurrent sessions there are proof of concept servers written in functional languages (like erlang) that handle an order of magnitude (!) more simultaneous sessions than what Apache does.

    I understand that for many here Apache is all they know and hence regard it as the holy grail but it is far, far, from being that. It is a good overall purpose web server but it is certainly not the fastest.

    In the face of the countless security holes that are all too common in C-written apps I'm now more and more installing pure Java web servers. At first I was using Apache + Tomcat now I'm more and more using Tomcat in standalone mode. Easier configuration, no buffer overflows to patch.

  • Careful with the php accelerators (Score:3, Informative)

    by graveyhead ( 210996 ) <fletch@@@fletchtronics...net> on Sunday May 27, 2007 @12:54PM (#19292849)
    I routinely experience Apache crashes while using eAccelerator, APC or Zend Optimizer, even with the latest stable PHP. If you use one of these products, be sure to also run some kind of watchdog that will restart httpd if (when) the stack crashes. They're totally worth running in any case. Zend Optimizer speeds up my Drupal installation by a huge amount because of the time saved parsing code.

    You also should of course make sure you've got caching happening at every level of your app. Memcached is a great application level cache. Apache side, make sure you enable and configure the memory cache for static files. (mod_mem_cache) and possibly the file cache (mod_disk_cache). Client side, make sure you're caching static files like images, js, css. Apache's mod_expires gives you good control over this in Apache config.

    Of course, all of this could be just spinning your wheels if you have badly optimized sql queries or bad table design to start with. Set mysql's slow query log threshold very low to catch these issues early.
    • You can try running php on Windows with IIS. Its alot more stable on the windows platform and IIS is no longer the POS it used to be. Also you may want to use a real mature language like java or .NET if you need stability and maturity. Php is very mixed.

      Of course I am probably going to be modded down here on slashdot for such a posting.

  • C code is one answer (Score:3, Interesting)

    by Anonymous Coward on Sunday May 27, 2007 @01:34PM (#19293083)
    I had a customer (I am a contract programmer, working on a per-project basis) who had an emmense PHP / MySQL application that ran so slowly it was unuseable. We did every simple optimization such as is described in this article, and more. In the end, the issue was clearly that there was simply a lot of PHP code, and a lot of it using PHP's objects, and searches through arrays, and that sort of thing. The biggest performance increases we were getting was when we could push some sort of comparison or logic from PHP into the SQL query.

    What we did was re-write all of the application except the parts that actually printed HTML to the page in C. We made that library into a php extension, which we added to our php installation. The speed ups varied according to the type of code, of course. MySQL queries changed hardly at all. A simple for loop might speed up from 100 to 1000 times, however, and a for loop that involved some sort of object oriented operations -- say, the creatation of a new object with each iteration, in an extreme example -- could be sped up from 10,000 to 100,000 times.

    Now, most code that was sped up 100,000 times, when examined closely, could be sped up in PHP also by writing it smarter. But bad C code still runs faster than good PHP code.

    If your disk drives are slow, or your code is printing a debugging log that has every function entry and exit to a network shared disk, or something like that, don't even think about C, just fix the basic problem first.

    However, in my experience, twiddling the apache configs for "AllowOverride" and stuff like that will never get you as big a speed up as moving PHP code to C.

    Note, that the way we did it, we moved all the core functionality and logic to a C library, but most of the display stuff was left in PHP. This meant that most ongoing development could continue to be done by cheaper, less skilled people who knew only PHP, MySQL, javascript, and CSS.
    • What were you doing that took so much CPU time? Shouldn't all the heavy lifting have been done by the database anyway? IMHO, it's pretty bad design to put too much sorting, filtering, etc. logic in the client code anyway, regardless of whether that client code is written in C, PHP or INTERCAL.

      That said, PHP is only a constant factor slower than C. A big constant factor, granted, but not 100,000. It appears that your perform improvement with the C rewrite came from algorithmic improvements, not a simple tran

    • Re: (Score:2)

      by lawpoop ( 604919 )
      What about optimizing the MySQL queries? I've found that lousy PHP programmers are even lousy database designers and query writers. Lousy PHP tends to make up for even lousier DB structure and querying.

  • Performance tuning and optimization of LAMP (Score:5, Informative)

    by kbahey ( 102895 ) on Sunday May 27, 2007 @02:45PM (#19293589) Homepage
    This is a set of articles on Drupal performance tuning and optimization for large web sites [2bits.com]. Although it says Drupal, much of it applies to the LAMP stack in general.

    It includes:

    • PHP op-code caches / accelerators: Drupal large site case study
    • Benchmarking APC vs. eAccelerator using Drupal
    • Drupal core caching and contributed content caching modules
    • Installing eAccelerator 0.9.5.1 on Ubuntu Feisty 7.04
    • logwatcher: restart Apache after a segmentation fault
    • MySQL InnoDB: performance gains as well as some pitfalls
    • MySQL my.cnf configuration for a large Drupal site
    • Presentation: Performance tuning and optimization of high traffic Drupal sites
    • Tools for Performance Tuning and Optimization
    • Tuning the Apache MaxClients parameter
    • Links and resources on Drupal performance tuning and optimization


    Disclaimer: this is stuff that I have written.

  • Biggest back for the buck... (Score:3, Informative)

    by sufehmi ( 134793 ) <sufehmi@@@gmail...com> on Monday May 28, 2007 @03:38AM (#19298105) Homepage Journal
    ...for most many cases, is to setup an edge server / reverse proxy. It will stop the load BEFORE it even reaches lighty / apache / whatever.

    It's very easy to do [sufehmi.com], take very little time, reliable & proven (which is not always the case with php accelerators), and will easily drop a double-digit server load to a single one.

    It constantly amazes me how people will do the hardest stuff which gave the minimum return first.
    Such is life I guess :-)

    If you want more proof, read this guy's article [turbochargedcms.com]. He sell a "turbo charged" Wordpress [turbochargedcms.com], got digged and overloaded, optimized his website and still overloaded. Finally his server managed to go through it after he implemented squid's reverse proxy.

    In summary - sort out your priorities guys.
    Biggest back for the buck first, and then go down from there.

  • PHP rocks on AMD64? (Score:3, Interesting)

    by ceeam ( 39911 ) on Monday May 28, 2007 @04:21AM (#19298239)
    BTW - I noticed that PHP5.2.1 on my home machine (Sempron64, Kubuntu AMD64, 2.0Ghz) to be consistently at least 1.5-2 times faster on (micro)benchmarks than the same PHP version "hand-built" with usual optimizations and the same AFAICT ZTS and other settings on Core2 Dual Xeon machine on RHEL4 i386 (1.8GHz). How comes? Is AMD64 ABI really that great for PHP or what? Python's benchmarks, OTOH, generally don't show any improvement between i386 and AMD64.
  • The blog site [sina.com] of sina.com(ranked 13 in global traffic by alexa index) is built entirely with PHP. It's the biggest blog site in China, with more 50 million users including thousands of Chinese celebrities. The blog site deeply use ajax techniques and has a video blog built also with PHP. My point is that if PHP can handle an interactive website(AJAX+Video) with more then 50 million users and more than 10 million page hit a day, what else in the 'net' PHP cannot do?

Slashdot Top Deals

E = MC ** 2 +- 3db

Close