Archive for August, 2006
Fast PHP
by Justin Silverton
The following methods can help improve scalability with php applications.
1) object code caching
Each time a request comes to your server for a php script, it has to go through the compiler and then execute the object code. If this is cached, the 1st step is skipped and you end up with a faster and more responsive script.
There are many object code caching packages available on the Internet (some free, some commercial):
A) Ioncube: http://www.ioncube.com/
B) Zend Encoder: http://www.zend.com/products/zend_safeguard
C) Turckl MMCache: http://freshmeat.net/projects/turck-mmcache/
2) Template systems
Template systems provide a different type of caching. Content caching. Template systems work well in a situation where there is static data on one or many of your pages that doesn’t have to be reloaded. Caching systems also provide a separation of code and html, which will not only improve completion time of the overall project, but make it easier for future improvments. Most template systems for php are available for free:
A) Smarty Templates: http://smarty.php.net/
B) Pear Templates: http://pear.php.net/package/html_template_it/redirected
C) PHP savant: http://phpsavant.com/yawiki/
3) Distributed object caching systems
The most widely used system of this type is memcached (http://www.danga.com/memcached/).
This type of system makes your overall site faster by caching the majority of your database data into a large memory pool.
an interesting excerpt from their site:
“Danga Interactive developed memcached to enhance the speed of LiveJournal.com, a site which was already doing 20 million+ dynamic page views per day for 1 million users with a bunch of webservers and a bunch of database servers. memcached dropped the database load to almost nothing, yielding faster page load times for users, better resource utilization, and faster access to the databases on a memcache miss.”
4) PHP variables that can be set
variables_order = ‘GPC’
register_argc_argv = ‘Off’
register_globals = ‘Off’ (this is a good idea to keep off for security purposes as well)
always_populate_raw_post_data = ‘Off’
magic_quotes_gpc = ‘Off’
Disable Error Logging. This is a good idea to keep on when you are developing your scripts, but it has been known to decrease overall performance.
Use IP address to access your database. Although this is sometimes not possible, you will get a slight boost in lookup speed if the IP address is used to access your database rather than its hostname.
5) Output Compression
Almost all browsers these days support something called gzip compression. Gzip compression can decrease the overall size of your output by up to 80%, but with a tradeoff: cpu usage will go up by around 10%. The benefit of using this compression type is the fact that not only will your bandwidth be decreased, but your pages will load faster.
enabling it in php (add the following lines to php.ini):
zlib.output_compression = On
zlib.output_compression_level = (level) (where level is 1-9. Youy may want to try different values to see what is best for your system).
if you are using apache, you can also enable the mod_gzip module. It is highly configurable, with the ability to modify output based on MIME types, files, or browser settings.
6) Other things that may help
when using a database, only retrieve the data that you are actually going to use. This may sound like a no-brainer, but I have often times worked on projects where the original programmer used (select * from mytable) when they could have used (select fieldIneed from mytable).
index database tables whenever possible
Learn more about this Here
specific language tricks
An interesting blog article I found mentions many interesting tricks that can be used: http://ilia.ws/archives/12-PHP-Optimization-Tricks.html
an article on zend.com about measuring performance: http://www.zend.com/zend/trick/trick-optimizing-php.php
PHP vs perl
By Justin Silverton
PHP and perl are both powerful languages used successfully in a server environment. Here are some brief differences between the two languages:
- PHP is built from the ground-up with database functionality built in, particularly MySQL functionality. Perl is not.
- PHP code gets embedded into HTML pages, unlike Perl. This makes it very fast to code web pages and fast to deploy a new site, thus speeding up Web development and lowering overall cost of ownership. An important code management technique for programmers is separating code from data. This allows us to make changes to the code or data without affecting the other. PHP uses the tags to indicate “code inside”. In Perl, however, programmers are encouraged to use print statements to generate the HTML. True it is possible to implement templates in Perl (with more difficulty than in PHP) to separate code and HTML, but 90% of sample Perl code on the web doesn’t do that.
- PHP is secure. Perl scripts tend to have more security holes. This is because PHP has built-in a lot of the internal operations of dealing with web page requests and serving information.
- PHP is easy to learn in comparison to Perl. It’s easier to learn than C, Python, Java, and most other programming languages used in web development, for that matter. The Perl style of programming is unique, and thus not universally applicable to or from other programming languages. Accessing web form variables in PHP is straightforward, but in Perl requires either detailed knowledge of either HTTP header formats or one of many Perl CGI libraries.
- PHP takes less “overhead” than Perl, meaning that PHP scripts will run faster than CGI scripts written in Perl, and you’ll be able to handle more simultaneous users on your site.
- PHP code tends to be more consistent and modular than Perl.
some other differences can also be found here: http://tnx.nl/php
A few of them are listed below (the rest can be found at the website listed above):
PHP has separate functions for case insensitive operations
(This can be argued both ways. Some think it’s good to have functions that combine functions, even if that means having dozens of extra names to remember)
In Perl, you use a double lc() (lowercase) or the /i flag where PHP usually provides a case insensitive variant. The case-insensitive versions have very inconsistent naming.
PHP has inconsistent function naming
- Case insensitive functions have the ‘i’ or ‘case’ at different positions in their names.
- There is no apparent system in underscore(s) versus no underscore(s):Perl has no core function names with underscores in them.
- PHP has unlink, link and rename (system calls), but touch (the system call is utime, not touch).
- And they can’t decide on word order:
- object verb: base64_decode, iptcparse, str_shuffle, var_dump
- verb object: create_function, recode_string
Perl core functions are all “verb object” except the superseded dbm* functions. (Note that sys is a prefix, not an object. And that flock and lstat were named after the system calls. shm* and msg* are library calls)
- “to” or “2″?ascii2ebcdic, bin2hex, deg2rad, ip2long, cal_to_jd (jdto*, *tojd), strtolower, strtotime,
PHP has no lexical scope
Perl has lexical scope and dynamic scope. PHP doesn’t have these.
For an explanation of why lexical scope is important, see Coping with Scoping.
[1] Perl has variables that are always in the main:: namespace. These are like PHP’s superglobals.
[2] Using a lexical variable in a sub routine’s block, you get a function local variable.
PHP has too many functions in the main namespace
(Using the core binaries compiled with all possible extensions in the core distribution, using recent versions in November 2003.)
[1] Source: PHP Quick Reference [2] Source: perldoc perlfunc