Modern frameworks comparison
Compares three different frameworks - Symfony2 (PHP), Django (Python) and Ruby on Rails (Ruby) - in their request handling performance, lines of code and average community on Github.
If you ask me, which one is the best - I can't point one, all of them are very good. But let's try to measure frameworks. For purpose of this article, I created three applications in Symfony2, Django and Ruby On Rails. All those apps do the same - show two tables, one shows top USA cities (by population), second shows US states with highest number of big cities (above 100k citizens). I don't want to measure frameworks by echoing "Hello world", because it's pointless.
Each of his applications use the same data set and use a default ORM with optimized queries, HTML rendered by an internal template engine and rounded floats. His performance requests (using Apache's ab) for this sample application show Symfony2 being able to handle the most requests/second followed by Ruby then Django. Symfony2 comes in at a larger file size than both the others combined, though. As far as the community is concerned, Ruby on Rails outpaces the others with about three times as many "watchers" on Github.
PHPUnit Aborted Fix
Ran into an issue with hit unit tests where PHPUnit was throwing an "aborted" error no matter what tests were run. Thankfully, in this new post, he shares a solution.
That was a pretty annoying bug. I never did find out what the problem was as I moved onto other problems and chalked that error up to some undiagnosed weirdness on that particular server. From time to time I would get asked on Twitter if I had ever solved the problem. My answer was always "no, and if you do solve it please let met know how you fixed it." Today, my friends, was the day.
Based on a response from Demian Katz, he was able to get around the issue with flag set on the PHPUnit command line - "-dzend.enable_gc=0". Apparently the issue has to do with garbage collection and has been a known issue since the beginning of 2011.
Building A RESTful PHP Server Understanding the Request
Starts off a new series (based on popular demand) looking at building an RESTful server in PHP. Back to basics - no framework, just PHP.
In the first part of this (probably) 3-part series, we'll begin with the basics. It might seem boring, but the most important thing to get right with REST is parsing all the various elements of the HTTP request and responding accordingly. I've put in code samples from from a small-scale toy project I created to make me think about the steps involved.
Her "basics" include:
- the routing to send everything to the main index file (a "front controller" of sorts) with the .htaccess settings included
- Handling the incoming request with a "Request" class
- Parsing the incoming parameters from the "php://input" stream
Never trust other peoples benchmarks - A recent example (exceptions)
In response to a previous post benchmarking exceptions, thoughts and benchmarking results.
Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".
He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:
So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.
