what's the "right" php framework?

Download What's the

Post on 23-Aug-2014

431 views

Category:

Internet

4 download

Embed Size (px)

DESCRIPTION

This is a presentation that I recently gave at UpstatePHP in Greenville, SC evaluating the framework landscape in PHP.

TRANSCRIPT

  • Whats the right PHP Framework? Barry Jones
  • Who am I? Barry Jones Java/Groovy/PHP/Perl developer since 98 Ruby on Rails developer mostly since 2012 Formerly ran Brightball, Inc here in Greenville Contract programming business from 2008-2012 99% CakePHP Built our platform The Intersect on top of Cake Software Architect with ACS Technologies, Inc
  • SO WHICH ONE IS IT? The people need to know.
  • Is it Zend Framework? CakePHP? Symfony? FuelPHP? Code Igniter? Lithium? Laravel? Solar? OR. Kohana? Yii? Prado? Akelos? PHP Fat-Free? Agile Toolkit? Silex? Phunction? K2F? Phraw? Qcodo? Slim? Phalcon? Roll your own?
  • WHY SO MANY? The million dollar question
  • Before we answer that Why do other languages seem to have clear leaders? Ruby has Rails Python has Django Groovy has Grails C# has MVC Java has Spring
  • Many solutions to the same problem usually indicates an underlying issue which leads to lots of trade offs
  • What does that mean for PHP? PHP is bad at frameworks out of the box
  • So lets dig into that a little Ruby, Python, Groovy, C#, and Java have something in common They boot up The application gets loaded into RAM Runs initializer code Makes its database connection(s) with a pool Listens for requests and only processes that request Can share RAM between requests Built for long term garbage collection
  • PHP Reprocesses everything on every single request Configuration Route mappings Database connections Loading all of those framework files Devastating to Disk I/O Encapsulates and garbage collects each individual process
  • So a PHP framework has too Cacheheavily And then reload those configuration caches on every request Per request RAM allocation is HEAVY Its not loaded once and then processed Framework is loaded every time for every request
  • A HISTORY LESSON Dont worry, well get back to the story
  • Rails lit the world on fire Javas Struts popularized MVCbut was awful Rails made MVC good And EEEEEEVERYBODY copied it as best they could CakePHP was a near clone for a while Microsofts MVC frameworkalmost carbon copy Grailsdo I need to explain this?
  • But why did Rails take off? Ruby is greatbut its not built for the web PHP is built for the web Ruby is an excellent language for writing Domain Specific Languages (DSLs) Think. Puppet, Chef, Capistrano, Vagrant Rails is a DSL for the web It changes Ruby to make it a web language That added to its popularity significantly in the Ruby community Nearly every Ruby library has a Rails version for premium integration Ruby developers are very big on testing because of the languages flexibility good at testing and easy to break Ruby developers place a premium on workflow Thats a heck of a lot more than just arranging some files and throwing routing and hooks on topthey built an entire mode of operation
  • This is important for PHP PHP is built for the web out of the box With no framework it can rock your face off
  • So why so many frameworks? Wellprior to PHP 5.3 PHP was terrible for frameworks for all the reasons previously mentioned Also, lack of namespaces made sharing libraries a PAAAAIN 5.3 was released in 2010 CakePHP 1.1 was popular in 2006 because it ran on PHP 4 and PHP 5 while structurally copying Rails The PHP framework wars started during a time when PHP was bad at frameworkshence the variety, saturation, and trade offs Everybody tried to solve the problem a different way
  • Prior to 5.3 you needed to Enable APC on the server Optimized PHP byte code cached in RAM Share RAM between process (under Apache mod_php only) In production, set APC to not check for file changes This got around the Disk I/O and overhead of reloading all those files Also drastically reduced per-request RAM With CakePHP wed go from 12mb to 2mb (also mod_php only) Configure a database connection pool within Apache OR ensure you were using MySQL because the overhead of new connections is almost negligible Avoid .htaccess files like the plague Every framework used them for pretty urls instead of having them added to a server config Setup a reverse proxy w/ nginx Intercept non-application requests prior to Apache processing .htaccess rules Use framework specific class loaders to try to load things only when necessary Frameworks had to roll almost everything themselves to avoid naming conflicts with outside libraries Extensive does this work with X? syndrome
  • So what changed? In 5.3 Late static bindings Namespaces In 5.4 Traits Artisan Built in Web Server CLI These allow Lazy loading Dependency injection Aspect Oriented Programming (AOP) Simpler development workflow Much easier library / package management
  • What is PHP good at? Scales down OR up better than any other language Boot up web languages cant scale down easily With PHP, you can fill up a hard drive with code and it will all work Other languages, you fill up your RAM and youre done This is why PHP shared hosting is everywhere and dirt cheap Encapsulation of each request provides near perfect server stability Tell me next time somebody uses PHP and Memory Leak in a sentence If a request dies it cant crash the server In its raw form, it can already do almost everything you need Example: Built an on-the-fly image processing server for a huge site Same functionality previously kept crashing Rails processes because memory leaks Increased efficiency by 3000% (seriously)
  • Ohand it can fly (the scaling up part)
  • What is PHP bad at? More on long polling PHP is bad at long running process Long polling involves many long running connections which for PHP means many long running processes which will vary based on the number of your users So for example: Optimal PHP request/response cycle Request received PHP started Libraries loaded/RAM allocated (2-12mb) Request processed Request ended, garbage collected Total time < .5 seconds (hopefully) Long polling PHP request/response cycle Request received PHP started Libraries loaded/RAM allocated (2-12mb) . (30-60 seconds) Request ended, garbage collected Total time 30-60 seconds Your servers RAM will be swallowed with a dramatically lower number of users from holding open dozens of 12mb connections You can make it work but in production youll have massive scaling issues from concurrency nginx_http_push_module This is not a php specific solution Request received with internal response address PHP started Libraries loaded/RAM allocated (2-12mb) Requested added to queue Request ended, garbage collected Total time < .5 seconds nginx holds the long polled connection instead of php Single background process pulls requests off the queue and processes them Sends response to the internal response address The background process handles responding to the long polling request so you control how many are running in parallel, not your user traffic nginx holds the concurrent connections efficiently (as good or greater concurrency than Node.js) Long running processes Please dont use PHP for long pollingever No really All those documents that say PHP is bad at long pollingdont take it as a challengethey mean it But if you must use nginx_http_push_module Alsomethod syntax consistency and assorted other quirks
  • But its more than just code The business problem: How do I find programmers who know this framework? Case: Brightball I loved CakePHP. It was complex, had a steep learning curve but was incredibly powerful We built a tool around it that would generate a permission controlled, data linked, interface based solely off of the database structure AKA The Intersect (we were big fans of Chuck) Really bad for billable hours Hard to find people who knew Cake (or any other specific framework) despite popularity numbers With complexity, training and learning curve are bad
  • This is where Code Igniter took off Code Igniter was not as awesome as Cake (sorry CI people) I know one of you wants to argue this pointyour opinion is wrong But it was a heck of a lot simpler Learning curve and training ease led to a huge following And Expression Engine
  • Not a problem in other languages Dominant frameworks lead to common knowledge bases among developers Hard to find a Ruby programmer that doesnt know Rails That allows continuous evolution because businesses avoid the training/hiring quandry Namespaces allows easy libr