Below are a list of my top five quick-and-dirty strategies for improving database performance in web applications. These suggestions are culled from recent experience and mixed with some ideas that I've implemented in my own code. They're not high level, but they are something we need consistent reminders about. Here they are...
Welcome to the first edition of the PHP performance series, a new series that I will be explaining ways to gain efficiencies and squeezing more performance out of your applications. This first edition, caching techniques, focuses on ways to cache data to optimize your current sites. Some of the concepts here are fairly easy to implement while others may take strategic design in the architecture of your application. Whether you are working on a high profile web application or simply a web development farm these concepts apply to the masses.
Mike Willbanks recently wrote a good article about performance tuning. There’s some good advice in there, and I thought it’d be a good idea to quickly add a bit more detail about the separate approaches that Mike raises.
Mike recommended using APC for bytecode caching. APC’s pretty good, but just be aware that APC isn’t compatible with Sara’s excellent runkit extension. Xcache is, but some versions of Zend Optimizer refuse to run if they detect Xcache has been loaded. (Btw, Zend Optimizer is worth looking at, but because of the way Zend compile it, it can affect overall scalability. I haven’t sat down yet and worked out whether Zend Optimizer’s performance improvements make up for the cost of how the Linux kernel has to load it into Apache. I touched on the issues with how things are compiled last year, but haven’t followed it up yet with any definitive figures on scalability.)
If you don’t need Zend Platform’s download server (which rocks), then XCache + Zend Optimizer + Memcache out-performs Zend Platform substantially, and costs a lot less too ;) Zend Platform also isn’t compatible with runkit. It’d be great to see runkit supported better by accelerators.
During a conversation on the TCPHP mailing list yesterday about frameworks and scalability I wrote a general reply on performance tuning for larger sites. The focus of this post is not to show performance related items to specific PHP frameworks since many bottlenecks actually apply before running the framework itself that should certainly be solved up front. Therefore in this posting I attempt to look at simple items that can be deployed in order to produce finer tuned systems.
I don’t believe I need to state why performance is important as we all know performance can make or break a site, application or even a business. To state up front; I do not deploy all of the methods listed here on every server, site and/or application as it truly depends on what I am expecting with traffic levels, server resource levels, etc.
Before I start
I’ve always stayed away from writing a performance topic. There seems to be a lot of performance enthusiasts, benchmarking anything they can, in order to scoop off a few more percent of performance time. To my opinion, if your system is already reacting within an acceptable fashion, there is no need to try to further improve performance. Maintainability is a much more important topic to look at, at that point.
Ever wondered where your PHP applications spend their time?
For simple PHP scripts you can easily do basic profiling by modifying your script, take the time at critical points and log the data to a file.
As applications become more complex or make use of third party frameworks like the Zend Framework this approach does no longer work well without introducing a lot of tracing code.
We wanted to gain performance insights of a newly developed application based on Zend Framework to spot areas worth receiving some fine tuning. We did not want to modify the application for that purpose so I had a look at the options available for PHP. I finally gave Xdebug a try. Xdebug is a debugger and profiler for PHP that works as an extension that you register in your php.ini ...
Following on the back of my recent posts looking at the (hopefully) best and worst of benchmarks I thought it would be useful to finish off with some genuine tips for creating 'lightning fast' websites. I probably lack the experience and insight to bring anything new to the table though so instead I'll point you to a selection of interesting articles.
Firstly, let's lay the benchmarking issue to rest. Ben Ramsey, who after his initial outrage at my 7 tips post felt it "actually is really humorous" (probably unjustified praise but thanks anyway!), has a nice post highlighting the code in the PHP source confirming the lack of any difference I demonstrated in my follow up post. Wez Furlong commented on my 7 tips post and highlighted a post he made on benchmarking back in 2005. For anyone feeling my method was excessive his approach gives speedier results. Personally I'd like to see it run in triplicate though.
I have recently came by the article “High performance websites” in yahoo developer network. This article pointed 13 key points to speed up your application. These are
1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags
I was trying to improve performance for a web application recently keeping them in mind. Let me describe how to do some of them technically.
In high performance web applications you will always have bottlenecks within your application. Identifying these bottlenecks and optimizing is a tedious task and typically show themselves underload. A single bad/unindexed query can bring a server to its knees. A large number of rows will also help to highlight any poor queries, and on very large datasets you may come to the point where you may have to make decisions whether to denormilize database schema.
PHP is a scripting language most often used to create Web applications. It's easy to learn and produces visible results quickly. However, because PHP is interpreted, PHP code is parsed and translated to opcodes every time it executes. An opcode cache eliminates that rework, making PHP applications faster.
News von
