Matthew Turland has this new blog post looking at some benchmarks he's generated for a group of mainstream PHP HTTP clients:
One of the interesting bits of research that I've done is benchmarking various mainstream PHP HTTP clients. Of course, we all know that there are lies, damned lies, statistics, and benchmarks, so take these with a grain of salt.
He ran them on his Sony Viao on Ubuntu with a stock PHP5 package. The tested packages were the pecl_http extension, the streams http wrapper, curl integration into PHP 5, PEAR::HTTP Client class and the Zend_Http_Client component. He includes the code he used for both a basic request and for something slightly more complex (posting form data). He used the XDebug and KCachegrind combination to produce the results.
On the Ibuildings blog today Lorenzo Albertontakes a look at the Zend Framework, specifically as to how it can mimic regular HTTP calls with the built-in components.
One of the unit testing best practices suggests to break dependencies, so you can test each component separately. The first problem that arises when you want to test controllers might be having a tighter control over the HTTP Request and Response objects.
This problem is overcome with the Zend_Test_PHPUnit_ControllerTestCase. The second problem it with calls to external resources (like models/databases or web services). This is the prime focus of the post and seceral blocks of code are included to make a class to emulate the HTTP responses you might get back from the service.
The Developer Tutorials blog has posted a new tutorial covering how to scan ports and checking a remote service's status with PHP.
Having access to the current status of public servers can empower your applications to make decisions and respond to problems automatically. Acknowledging a service is offline can also save endless support emails. In this tutorial, I'll show you how to keep track of your server status by scanning ports on your server with PHP.
They show how to check a remote instance (a socket open with a timeout) and how to run through a list of ports, looping from one to one-thousand and running an fsockopen on each. They make a sample script to show these two combined - a simple page that loops through the common protocols (HTTP, FTP, SSH, etc) and checks to see if the remote machine is running something on that port.
On the PHPFreaks website, there's a new tutorial talking about sessions and cookies in PHP:
HTTP is a stateless protocol. This means that each request is handled independently of all the other requests and it means that a server or a script cannot remember if a user has been there before. However, knowing if a user has been there before is often required and therefore something known as cookies and sessions have been implemented in order to cope with that problem.
The tutorial is pretty introductory, so if you're not new to the PHP world, you won't learn much. New developers, though, will learn how to set cookies, use sessions and learn a bit about the security of both.
Lukas Smith has posted the second and third parts of his talk with Rasmus Lerdorf - a look at MaxClients and HTTP headers.
As promised here are the two other logs from the recent chat I witnessed. [...] Again I left the logs in their raw original way. Hope they are useful for you all.
Lukas also links to tworesources he mentions in the second (third?) log about performance as well as mentioning one of the most useful Firefox extensions for web developers - YSlow!.
Akash Mehta has pointed out five "PEAR gems" that can help you get your code up and running faster - some helpful bits of code to help you deal with some common issues.
Sifting through the repository is also a challenge; a basic category system is in place, but it's hard to tell what you want when you don't know what's available. Here are some gems from the PEAR repository that you could really find useful.
On his blog today, Stoyan Stefanov has a howto posted on a trick he figured out to get a PHP script to grab data from multiple resources at one time - with cURL.
The basic idea of a Web 2.0-style "mashup" is that you consume data from several services, often from different providers and combine them in interesting ways. This means you often need to do more than one HTTP request to a service or services. [...] Using the curl_multi* family of cURL functions you can make those requests simultaneously. This way your app is as slow as the slowest request, as opposed to the sum of all requests. And that's something.
He includes example code that loops through a given array of resources and executes the fetch, brining the results back into a result array. To illustrate, he also includes two types of examples of fetching content - one for GET and another for POST.
On the PHP in Action Blog, there's a this post that shares some tips for testing your web applications with some simple tests.
I just started listing the techniques I've learned when writing tests to exercise the web interface of a PHP application. This is from my experience and my personal preferences; it's not the final word or necessarily right for everyone.
He suggests:
Use SimpleTest's Web tester if you can
Test the web output using regular expressions
Use element IDs or names to test links, forms and fields
Mike Willbanks has posted an introduction he's written up giving some helpful hints at tuning your servers and PHP applications for performance.
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.
Jonathan Snook has posted a helpful trick for CakePHP users out there looking to secure sections of their site away from "normal users" and keep it only in the hands of the admins.
I just wanted to document this for easy future reference but if you don't want to hook up a complex user adminstration with authorization components, you can simply specify that the admin path be password protected in either your .htaccess file or in your httpd.conf.
This method is actually one of the built-in methods Apache has for restricting access (http authentication) that he's placed on his "/admin" directory. Call htpasswd to create the password file and you're all set to go.
