php|works Toronto Conference 2006: Day 2
Day 2 of php|works is a wrap, another great day of tutorials and information. Above that, the Holiday Inn is providing great service, refreshments and food. I’ll link to slides below as they become available. A summary of the day and interesting stuff learned follows…
9:00am – 10:00am: Microsoft Platforms for the PHP Developer by Joe Stagner
The day started off with Joe Stagner from Microsoft Canada giving us a one hour talk on PHP and Microsoft. There were a bunch of people there from MS giving away .NET migration books, Visual Studio Express CDs and other propaganda. I guess in the worst case, they would want us to develop/deploy on the Windows platform instead of Linux.
The talk went on about a lot of things including native COM access through PHP, .NET integration with PHP, PHP4Mono and more.
Joe’s slides
10:15am – 11:15am: Cache For Cash by Ilia Alshanetsky
I sat in on two outstanding talks today, the first was this one, and the second was the next (Flash + PHP). So what’s the motivation for caching? Simply put, the PHP engine and MySQL operations present an overhead in parsing, compiling, processing, etc… when displaying a single page. In most cases though, not everything on the page is dynamic, and doesn’t require the PHP engine to be invoked every time.
In Cache for Cash, Ilia went through six ways to cache and how one would go about implementing them. I’ll briefly go through each…
Complete Page Caching
As the subtitle says, this is the process of taking a dynamic page, and storing the generated contents in an HTML file. When the site is loaded, instead of running the PHP script, the server would load the static HTML page.
I have no way of verifying this, but I’m pretty sure WordPress, Blogger and other large scale hosted blogging engines use complete page caching. This makes sense, since most people won’t make a new post that often, and when they do, the entire page could be re-generated instantly.
Ilia quoted a greater than 40% improvement in latency when caching his pages using the blogging engine Serendipity. Caching could be taken even further, to check the browser encoding header for GZip, and if so, send the GZip’d version of the page, instead of the original. In many cases this could cut down in half the amount of data being transferred over the wire.
Content Pre-generation
Imagine you have an online store front selling 1000 products (0 through 999). Each of these products have a product description page, say by desc.php?id=xxx, the xxx would represent the numbers ranging from 0 through to 999. Since your prices wouldn’t change that often, you could write a script to generate all 1000 pages, and have the application call these pre-generated, cached files. The general theme here is simple: remove PHP from whatever you can. This is what Livedocs does; they improved their latency from 611.2 ms all the way down to 2.37 ms, because they removed both PHP and XSLT from the equation.
The secret here is not to just store the static pages on your normal HTTP server. Since the pages are static, you should use a light weight server, like lighthttpd, which would have a very fast response time. This type of caching doesn’t come without its problems; first off disk space could become an issue through so many files being generated. Furthermore, ext begins to suffer when the file system surpasses a certain number of files. Secondly, you could be easily pre-generating pages which might not ever be used. If you have thousands of pages, your wasting disk space, and before the page is ever used, it might need to be re-generated again.
On-Demand Caching
The idea here is to generate what you need, when you need it. Depending on what you’re doing, this could be a really good option. When I first heard On-Demand Caching, the first thing that came to mind, was MagpieRSS. This package grabs a given RSS feed (or XML) on demand, and gives you the ability to use the results in your application on the fly. If the headers of the given feed indicated that the XML hadn’t changed, then the cached version of the file was used locally for parsing, instead of downloading it all over again.
Ilia gave a cool idea on how to implement On-Demand Caching: Have all pages initially display a static HTML page. The short PHP code that would load this static page, would first check if the given HTML had been updated. If so, the script would throw a 404 error, instantly sending the user to the 404 page. There is nothing stopping you from creating a custom PHP 404 page, that looks at the URL it came from, and auto-generates the updated (new) content for that page. The new page would not only be displayed to the user, but also cached for future requests. The only issue here is that your logs might get cluttered with false error messages.
Partial Page Caching
The idea here is to have a light weight http server providing all static pages, in conjunction with dynamically generated content. Full caching is not possible in this case, since the pages have dynamic content, that can’t be avoided. To improve the latency of the dynamic content though, an APC style middleware should be used. I’ve gone through APC briefly in the summary of day 1, but here’s a bit more. With APC you have the ability to manually put data into shared memory. There are basically three functions you need to know:
apc_store([key],[var],[time till expiry]); — place data (var) into memory using a [key] and have it expire via the third parameter
apc_delete([key]); — remove the data associated with [key] from dynamic memory
[var] = apc_fetch([key]); — grab data from shared memory using a [key].
SQL Caching
Ilia made an interesting statement at this point, he said many application work with a database, but few do it efficiently. We learned about three types of SQL caching:
DB SQL caching: Say your blog has 10 commonly used search terms. Rather than having your site go through these expensive searches each time, you could cache them in a separate SQL table. This makes sense, since a single table read in MySQL is very fast, and the results would come back almost instantly.
On-Disk SQL Caching: Using the example above, rather than storing the search results in a single db table, you could store the results in a file. This has a similar idea to page caching.
In-Memory SQL caching: This is the same idea as above, just you would be storing SQL data in memory using APC or SHMOP. APC is meant for PHP Opcode caching, but there’s nothing stopping your from storing SQL results data instead.
Browser Caching
This type of caching virtually reduces the data sent from the server to 0. The problem here, is that browser caching is not guaranteed and every browser implements this differently. There are three ways to implement browser caching from a PHP application:
header(“Expires:”…. This tells the browser to hold this page till a certain time
header(“Last-Modified:”…. This puts all the control in the browser, as to when to re-fetch the page
header(“Etag:”…. This is the most reliable method, by sending a unique identifier check-sum to the browser, notifying it, that the page has changed
Ilia’s slides
11:30am – 12:30pm: Flash + PHP: an Alternative to AJAX by Christian Wenz
Christian is a great presenter. He has a distinct style, were he likes to talk and show examples rather than follow/read off slides. He tries to make the talks seem like he’s coming up ideas on the fly, but its easy to see he’s thought through everything he wanted to say.
This talk focused on how a PHP programmer can use Flash to easily make rich UI applications. The presentation covered an introduction to Flash, how it integrates with PHP, demo applications, and finally Macromedia Flex. I’ll just cover a few highlights.
To begin with, Flash is semi-open standard, along those lines third part tools exist for developing Flash applications, but their always behind the Adobe developed Flash development studio. The Flash scripting language is called Action Script, similar to Dojo style JavaScript, Action Script is an ECMA approved Script Standard and in recent years has really begun to gain a lot of power and functionality.
An interesting development coming up is Flash Light. It appears this is going to be a light weight version of Flash, which would be used to develop application for mobile devices. These application would run standalone on a phones OS, outside of any type of browser.
Flash and PHP
A developer has many options to connect with PHP when creating Flash applications. The original way was to use the Action Script functions loadVariable and getURL. From here loadVars came about, which was an OOP version of loadVariable, now allowing for a callback function to handle results.
Probably the most interesting way to connect with backend logic is to use Flash’s inherit ability to work with Web Services (SOA). With SOA, the developer can create their business logic, wrap it in a WSDL and have a desktop application, web application, Flash app etc. all run off the same code. The world is moving towards SOA, even MS ;)
The most complicated method of connecting with a backend, had to be Flash Remoting. This was some intense binary data transmission method, based off of AMF (Action Message Format). The Macromedia supplied version of AMF is very expensive, but luckily there are open source alternatives including AMFPHP and PHPObject.
1:30pm – 2:30pm: Derick’s Ranting Hour by Derick Rethans
This was a light-hearted, open discussion on PHP, by the people who actually develop the language. The slides include funny examples of bug reports, emails and more.
2:45pm – 3:45pm: The State of AOP in PHP by Sebastian Bergmann
In this talk, Sebastian gave an introduction to Aspect Oriented Programming, examples of syntax, theory and how he was going about implementing this in PHP. To get a good understanding of AOP, you’ll need to do some good research.
Have a second? Check out this great Canadian Health & Living Store based in Toronto