Link to home
Start Free TrialLog in
Avatar of delphiheaven
delphiheaven

asked on

Highperformance with PHP???

Hi,

I wonder if there are hints and tricks for highperformance-websites programmed in PHP?

Are there points/details which can improve the performance and speed of PHP?

Or is improvement of performance only possible by proper installation and settings of the Webserver and of the Database-Server?
ASKER CERTIFIED SOLUTION
Avatar of Richard Quadling
Richard Quadling
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Yes, there are a few things. My main complaint is PHP programmers who retrieve a whole recordset from a database into PHP, and then go about using PHP array methods to search through the data. This should only be used as a last resort. Do all your data manipulation in SQL. Return only the data you need to show on at that particular point.. no more.

A small point, but if you are echoing (or printing) a string with no variables, use single quotes (so PHP doesn't even look for variables).

There is the compile-time option --enable-inline-optimization, which speeds PHP code.

Zend Optimizer is free, and can speed up complex scripts by approx. 50% (simple scripts cannot really be sped up much anyway). Zend Accelerator costs money, but maintains a compiled cache of your scripts in memory, which is about as fast as it gets.

Choose a good database management system, and choose good database design. This single area is probably the MOST critical point of failure in most PHP websites. (I recommend PostgreSQL, Sybase, Oracle, etc... over MySQL if you have any complexity in your system. MySQL is fine for simple websites, though.)

As JD says, HEAP tables in MySQL provide very fast access, but there are a couple hidden costs in MySQL HEAP tables: 1. No column can be greater than 255 characters, so if you are storing larger values, you must come up with a way of spanning multiple columns or records.
2. MySQL locks HEAP tables upon update, so if you have many sessions being written at the same time to the same table, you will hit a bottleneck fast. (one solution is to create a separate, temporary table for each user session. The other solution is to forget MySQL and compile PHP with 'mm' shared memory support, and use the mm storage handler for sessions, which accomplishes the same thing without using a database)


Really, though, PHP is already a high-performance platform. It is very well optimized for speed. The main thing to think about is scaleability, and your own architecture:

Architecture:

- Are you repeating any code blocks that you could put into a standard include?
- Are you loading more code than you need at any one time (conditional includes are a great thing)?
- Is your design modular, so that similar things are handled by the same function/class, etc...? (This way, you can optimize one function and your whole site will speed up.)

Scaleability:

Scaleability is still a bit of an issue with PHP. There are a couple interesting add-ons available, such as http://www.php.net/msession (clustered session daemon), and SRM (www.vl-srm.net). Other than this, you have to think about how your application can be run on multiple servers, using standard clustering technology. The simplest method is to use something like msession, or to store sessions in a central database, and then use multiple front-end webservers, and one master database server (which can be clustered/replicated according to the DBMS's abilities.) This way, your front-end webservers only contain code, without needing to maintain ANY data persistence, since that is handled by the database, for application data AND for session data. ON the other side, the SRM system actually allows for 'back-end' PHP scripts, which run independently of an HTTP request on the server, but which provide business logic and database pooling to the PHP front ends. I'm sure there will be a lot more work done in both of these areas during the coming year.

Good luck

(P.S. Hello my friend JD ;-)... )