Tag Archives: Performance

Lone Star PHP takeaways

Thanks to the guys at Engine Yard, I won a free pass to the Lone Star PHP community conference in Dallas, TX this year. Due to the choice of subject matter and presenters, I think I enjoyed this conference even more than last year’s PHPCon in Nashville. Here are some of the highlights.

Day 1

!Normal===Awesome!

Cal Evans inspired us all to go out and build awesome stuff, and that we owe a debt to the giants who came before us and gave, to give to those coming after.

  • “This stuff is hard. If it looks easy, it’s because I’m good at it.”
  • Get involved somewhere.
  • Be a builder, a speaker, a teacher.

Building Testable PHP Applications

Chris Hartjes delivered a really helpful talk on testing applications. One of the big obstacles of unit testing for me was mock objects. Chris did a good job explaining how they are used in the context of PHPUnit. Key takeaways for me:

  • Automate test execution.
  • Following the law of demeter will make your applications easier to test.
  • Code in a framework-agnostic and environment-agnostic way.
  • PHPUnit provides methods for setting up mock objects, so you don’t have to actually define those classes.
  • Test private/protected methods and properties by using a Reflection hack. Etsy’s PHPUnit extensions can automate this.
  • Don’t access the database in Unit tests, use mock objects instead. Filesystem access can be mocked using vfsStream.
  • Some applications resist testing, no matter what. If you cannot refactor, you can still automate tests with Behat.
  • If you don’t test, Chris will cut you!

See his slides at SpeakerDeck.com.

PHP Extensions for Dummies

Elizabeth Smith laid bare the innards of PHP in her intro to PHP extension development. Much of it was unintelligible to me since I don’t (yet) know C. However, now I know who to go to if I need help compiling an extension! If I can navigate the dependencies, I’d like to try compiling a non-thread-safe Windows build of php_wkhtmltox for a future blog post.

Pixel Punching with PHP

Bob Majdak‘s presentation compared the usage and performance of GD2 and IMagick across a number of common image manipulation tasks. IMagick is better in almost every way.

See his slides at SpeakerDeck.com.

Day 2

It Was Like That When I Got Here: Steps Toward Modernizing a Legacy Codebase

Paul Jones‘ keynote did not disappoint. With insight and humor, Paul dismantled the problems with legacy codebases and presented a logical methodology to improving your life when you are forced to inherit a big stinkin’ pile of spagetti code.

  • No matter how bad you want to, resist the urge to throw it out and rewrite.
  • You’ve nothing to lose. Either bear the pain of bad code, or bear the pain of refactoring bad code. May as well put the suffering to some use.
  • Move class files to a common base directory and autoload, removing require/include calls as you go.
  • Change class names as you go, if needed.
  • Wrap procedural functions in a class, so that it can be autoloaded.
  • Replace globals incrementally, moving them first to the constructor, then replacing them with dependency injection

SOLID – Not Just a State Of Matter, It’s Principles for OO Propriety

Chris Weldon laid out five principles to get the most out of object oriented development.

  • Single responsibility: each class should do one and only one thing.
  • Open/Closed principle: each class is open to extension, but closed for modification. Don’t break stuff.
  • Liskov Substitution principle: replace if…else constructs and prevent exceptions by using typed collections.
  • Interface segregation: each interface should be as focused as possible, so that it can be used by as many classes as need it. Similar to the Open/Closed principle, applied to interfaces.
  • Dependency Inversion: injection dependencies from the outside, don’t couple on the inside.

Fast, Not Furious: Performance Tuning that Works

Davey Shafik demonstrated how to use xhprof/xh-gui and Memcache to optimize your PHP application.

  • 1. Benchmark. 2. Profile. 3. Change.
  • Profiling affects performance, similar to quantum observation.
  • Benchmarking tests actual runtime, from start to end.
  • Namespacing Memcache keys can help overcome the 1MB size limit
  • Create new namespaces, don’t clear the cache. Garbage collection will clean up the old unused namespaces.
  • “Hardware is cheap, programmers are expensive” only holds when you take care of your hardware.
  • Don’t make assumptions, test everything sequentially.

Takeaways from PHPCon, day 2

Get my day one takeaways here.

Day two at PHPCon in Nashville, TN was packed with lots of information that frankly, I’m still digesting. It was well worth the trip and ended much too quickly!

Download my notes (PDF)

Morning Keynote

In his “brain dump,” Rasmus Lerdorf shared a collection of unrelated but very useful tips and observations about PHP.

  • PHP is the bottleneck, there is no significant difference between nginx/lighthttpd/apache
  • Error handling is not optimized in PHP because it should be an infrequent event. Set error_reporting = -1
  • Insufficient realpath_cache_size in PHP 5.2 can cause excessive filesystem STATs
  • Use gearman for out-of-band processing. Threads aren’t needed in PHP.
  • Don’t overload apache (8 core CPU = 25-30 apache clients; never more than 50)
  • Deploy processes should be atomic and robust (can use Capistrano or Rasmus’ own weploy script)
  • Node.js-style event programming is fast and easy (see http://php.net/libevent)

Slides: http://talks.php.net/show/phpcon2011 (ya gotta love the homegrown web-based presentation system!)

The Original Hypertext Preprocessor

Drew McLellan‘s presentation was particularly relevant for me in my role as CTO at Company52, and I consider it one of the best presentations at PHPCon. Drew’s goal was not to market Perch (although he did an awesome job of it without even trying), but rather to share his philosophy of what really great client support is all about, and how it has impacted his work.

  • Throwing new features at a problem often doesn’t solve it. Functionality is not enough.
  • Find ways to reduce support requests.
  • Every support request should be unique (no FAQs).
  • Fix areas of confusion rapidly.
  • Support your own software – programmers should see issues firsthand.
  • It’s OK to be opinionated (“WYSIWYG is evil”), but don’t be dictatorial. It’s not our place to tell people how to work.
  • Help customers look good in front of their clients.
  • Accept when users are having problems.
  • Really great developers solve problems. Excuses simply are not helpful.

The WonderProxy story

Paul Reinheimer shared the story of how he built (and self-funded) WonderProxy, born out of a personal need to test applications that use IP-based geolocation.

  • Mistakes – “crouch and hope you don’t get hit”
    • No account de-activation
    • NIH – wrote paypal IPN code instead of re-using own code
    • Mixing Linux distros
    • Server account renewals
    • Afraid to look at profitability numbers
  • Old strategy: blog about problems we encounter – competitors find posts
  • New strategy: blog about problems customers have – bring customers instead of competitors

Is it Handmade Code If You Use Power Tools?

Laura Beth Denker of Etsy shared an overview of their continuous integration processes, and how it has greatly improved both confidence and deployment speed. True to Etsy style, Laura came dressed in a handmade outfit from a Nashville-based Etsy vendor, earning a “too much swag” tweet from one listener!

  • NEED CONFIDENCE in your code
  • Effective testing strategies include functional (human) testing, integration testing (database), and unit testing (foundation)
  • Don’t use random data in unit tests
  • Test each case in control structures
  • Use DBUnit for testing database interaction
  • Tests should run rapidly
  • Group unit tests and target test groups to run
    • caches
    • databases
    • network tests (third-party APIs)
    • sleep
    • time
    • smoke, curl, regex
    • flaky

What happened to Unicode in PHP

Andrei Zmievski’s talk was a frank de-briefing of the failed attempt to bring native Unicode support to PHP6. Although this story is a rather personal one for Andrei, he was honest and incorporated a few surprisingly hilarious bits of humor. The conclusion: native Unicode support will only come to PHP if and when the community wants it — and is willing to put noses to the grindstone. The task is simply too big for his elite band of 10 (including Rasmus himself). Most of the content was historical in nature, but there were a few nice tidbits of information.

  • Complete I18N is more than language stuff:
    • Character set
    • Date/time formats
    • Currency formats
    • Collation (sorting, contractions – thanks to Andrei for finally helping me to understand what a “collation” is)
  • pecl/intl has some useful classes left over from the PHP6 unicode project (Collator, NumberFormatter, MessageFormatter)

Closing Keynote

Terry Chay’s closing keynote wove a common thread through all of the presentations given at PHPCon, along with a heaping helping of humor (seedy at times). My favorite part were the Chayisms: http://phpdoc.info/chayism/

Takeaways from PHPCon, day 1

I’m here at PHPCon, the first PHP community developer conference in Nashville, TN. The first day consisted of two rather lengthy workshops, both of which were very informative.

Download my notes (PDF)

Web Services

This talk was given by Lorna Jane Mitchell, whose totally awesome British accent I could listen to all day. I consider myself no novice on consuming web services, but being a relative newcomer to building web services, I got a real education on how to do it right.

Key takeaways:

  • Use curl, it eliminates points of failure for more accurate testing. Lorna rejects any bug ticket that does not come with a curl test case, which reduced support requests by 50%!
  • Every web service should have a heartbeat method that echos the variables you pass to it.
  • Every web service should have documentation, (real) examples, and a support mechanism. If you’re not going to do this, don’t bother building a web service, ’cause nobody’s gonna use it.
  • Utilize the HTTP protocol as fully as possible, including HTTP headers (Accept, Content-Type, User-Agent), verbs (GET [read], POST [create], PUT [update], DELETE [delete]), and status codes (HTTP 200, 201, 301, 302, 400, 401, 403, 404, and 500).
  • Give consumers a choice of formats. text/html is useful for debugging purposes.
  • Parse the Http-Accept header and deliver content in first format listed that you support.
  • Don’t confuse HTTP 401 with HTTP 403 (“I don’t know who you are, so I’m denying access” vs “I know who you are, and you don’t have permission”).
  • pecl_http is an easier way to access web services than curl.
  • Error handling defines API quality. Provide complete, useful, and consistent error messages in the expected response format.

Link bundle: http://bit.ly/bundles/lornajane/2

Frontend Caching

This talk was given by Helgi Þorbjörnsson (I will not even attempt his Icelandic surname). Helgi is a long-time PEAR contributor and experienced front-end developer. Key takeaways:

  • 80% of response time is spent downloading resources.
  • Don’t abuse cookies. Large cookies hurt performance because of slow upload speeds, and because they are sent with every request. When you use cookies, be sure to set an expiration date and limit them to only the domains they are needed on.
  • Browsers have per-domain concurrent download limits. You can spread static assets across 3-4 multiple subdomains as a workaround.
  • Combine files judiciously. Be aware of the trade-off between fewer server requests and larger file size.
  • Load above the fold first.
  • Minify Javascript and CSS, preferably at build time.
  • Use gzip compressiononly for text-based content.
  • Save HTTP 404 bandwidth by ensuring that you have a robots.txt file and a favicon.
  • Compress images more (Photoshop doesn’t cut it; better alternatives include pngcrush and jpegtran).
  • Test with slower connections (tread the user’s path).