PHP
Article
By Bruno Skvorc

Up and Running with the Fastest PHP Framework on PHP7 in 5 Mins

By Bruno Skvorc

You may remember our past infatuation with Phalcon, the fastest PHP framework.

In this post, we’ll go through the process of getting it up and running in 5 minutes on one of our Homestead Improved instances. If you’re not interested in why or what Phalcon is, just skip ahead to “Setting it up”.

Phalcon PHP logo

Recap

If you’re not familiar with it, Phalcon is a PHP framework written in Zephir, a language mid-way between C and PHP that helps in developing PHP extensions without having to know C. It’s a golden middle ground which lets PHP developers develop highly optimized modules for their programming language environment without the overhead of learning a completely new language, because Zephir compiles into C, which is what PHP extensions are made of.

Originally, Phalcon was an extension written in pure C – which made it incredibly fast. However, this also introduced massive overhead in fixing bugs or inspecting what’s going on under the hood when something doesn’t work the way it should. It also took ages to add new features, since developing in C is so much more difficult. In version 2, Phalcon was rewritten in Zephir, but as PHP 7 was looming on the horizon and announced a dramatic departure from the extension API of PHP 5+, Zephir could not compile code to PHP 7 compatible extensions and was left behind in PHP 5 land.

We try to walk the bleeding edge here, and there was no more room for Phalcon in our arsenal. With our Homestead Improved box up and running and powering all our tutorials, and with PHP 7’s performance advances making up for any kind of speed gains Phalcon may have offered in PHP 5 time, the cost of installing Phalcon was no longer worth it in any way.

Recently, things have changed: Phalcon went 3.0 LTS.

Apart from following Semver from now on, supporting the 3.0 version for the next 3 years, and various new features and changes you can read about in the post, the biggest update by far is the fact that Zephir now supports PHP 7, and allows for not only the compilation of Phalcon, but also the compilation of any other Zephir code into PHP 7 as well. You can now easily port your custom extensions to Zephir, and have them compiled into PHP 7 in a jiffy. A compiled framework combined with PHP 7’s performance gains offers unparalleled advantages in terms of speed and resource conservation.

Setting it Up

We’ll now go through the process of setting up Phalcon 3 on a PHP 7 powered Homestead Improved instance. You can use any kind of environment you feel comfortable in, but the instructions below will be specific to an Ubuntu 16.04 instance with PHP 7+ installed, and things like Git and Wget present. We’ll also use the Homestead Improved way of defining new sites, via the Homestead.yaml file.

Installing Phalcon

sudo apt-get install software-properties-common
sudo apt-add-repository ppa:phalcon/stable
sudo apt-get update
sudo apt-get install php7.0-phalcon
sudo phpenmod -v 7.0 -s ALL phalcon
sudo service php7.0-fpm restart

The second to last command is a shortcut command to enable a PHP extension. The -v flag tells it which PHP version to activate it for (we want only 7.0 here) and which SAPI (command line, FPM, or both – we want both).

If this tool is not available on your system, then just copy the ini file into the extensions folder like so:

sudo cp /etc/php/7.0/mods-available/phalcon.ini /etc/php/7.0/fpm/conf.d/20-phalcon.ini
sudo cp /etc/php/7.0/mods-available/phalcon.ini /etc/php/7.0/cli/conf.d/20-phalcon.ini

The 20 prefix indicates priority, in case some extensions need to be loaded before others. This is not the case here.

We’ve now unleased the beast. Looking at phpinfo(), it’s there.

Phalcon is active in phpinfo

Demo Phalcon App

We can test things on a demo Phalcon application – the finished Invo app.

Configuring Nginx for Phalcon

We need to add our app into the Sites block of Homestead.yaml:

    - map: phalcon-tut.app
      to: /home/vagrant/Code/phalcon-tut/public

Make sure phalcon-tut.app or what ever vhost name you choose is added to your host OS /etc/hosts file in order to resolve to the VM’s IP address.

Of course, we also need to run vagrant provision outside the VM in order to apply this Nginx setup.

Finally, we edit Nginx’s location block, and change from

location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

to

location / {
        try_files $uri $uri/ /index.php?_url=$uri&$args;
    }

We need to restart Nginx to apply the changes:

sudo service nginx restart

This takes care of the server end of things.

Bootstrapping the app

cd /home/vagrant/Code
git clone https://github.com/phalcon/invo phalcon-tut

Once the app has been cloned, we need to initialize its database, as per instructions. We’ll update those to be a bit more modern, by using utf8mb4 instead of utf8.

echo 'CREATE DATABASE invo CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci' | mysql -u homestead -psecret
cat schemas/invo.sql | mysql -u homestead -psecret invo

There’s one more step which isn’t described in the app’s repo – changing the baseUri in the configuration. We have to go into app/config/config.ini and change baseUri to /, otherwise assets (JS/CSS) will fail to load.

After doing that, sure enough, INVO is up and running.

Invo screenshot

Conclusion

In this tutorial, we quickly configured Phalcon to run on Homestead Improved and PHP 7, and got a demo app up and running. With installation instructions significantly simplified compared to what they were, and with ready-made apps to test it out thoroughly, why not go for a Phalcon test run and tell us what you think?

Now that Phalcon is available on PHP 7, will you be using it for any of your new projects? How do you feel about Zephir – would you use it to close-source or hyper-optimize any of your microservices / modules, or do you still feel like that’s too much overhead?

  • Any benchmark comparisons available yet?

    • Bruno Škvorc

      Nope, but feel free to let us know if you perform some. I personally think benchmarks are pointless, as the speed of a hello world page can be optimized to kingdom come and then the real world application performance will differ immensely depending on context, but I know some people do care about this sort of thing so I’m not completely opposed. One thing to keep in mind is that Phalcon will *always* be faster than the competition purely because it’s compiled and being run (and pre-loaded) from C.

      • Attila Fulop

        I completely agree on that existing benchmarks are pointless. Just one real-life example: after long periods of symfony projects when any of my teammates jumps to Laravel, they start moaning oh how good it is that Laravel loads immediately, and I don’t have to wait seconds to load like with Symfony.

        Contrary to that, Symfony always beats Laravel in benchmarks.

        Of course in production you optimize the hell out of it, but Varnish does wonders with anything :)

  • Attila Fulop

    I am personally a big fan of phalcon and did convert a project last year from konekt framework to phalcon. It was a very joyful thing thanks to phalcon’s great flexibility.

    I also did another project with phalcon from scratch and it was fun too.

    Last week I upgraded one of these from php 5.5/phalcon2.1 to php7/phalcon3 and was very seamless.

    On the downside I’m missing a concept similar to Laravel’s Service Providers or Symfony Bundles. This probably would help others (even me) to start developing reusable extensions for phalcon that this cool framework unfortunately lacks yet.

    • Bruno Škvorc

      Just develop plain old PHP packages for Composer/Packagist, no need for bundles and service providers – they’re all just shortcuts for DI containers anyway, and needlessly couple your package to a framework. Make something that works everywhere, and instruct people on how to use it well with a DI container instead.

      • Attila Fulop

        That’s the theory. Actually when you have to do something concrete, you choose right at the start at it’s minimum an ORM, so it’s immediately coupled to something more than just php. If you try to do it in a framework agnostic way, you end up in a serious design headache due to heavy abstractions.

        Do you use collections or just plain arrays? If collections which one? Illuminate or doctrine collections? Why? Plain arrays? Good luck with filtering, shrinking and other nice tasks on the go.

        Which event/listener implementation will you use? All frameworks have their own. I was using a composer package wirh phalcon that relies on the very popular symfony events implementation. There’s nothing that fits into phalcon’s own event system.

        Will you use SQL or some NoSQL like Mongo? Will you use a Datamapper or some ActiveRecord ORM?

        When you answer all these questions you’ll end up with a series of decisions that will tie you to other libraries/frameworks, at least for usual business applications.

        I am actively maintaining some projects on packagist/github and my experience is that simple libraries can be framework agnostic. But for a more complex set of components (eg Sylius) it’s not a real life scenario.

        • Bruno Škvorc

          But everything you list (ORM, Datamapper, event listeners) has a framework-agnostic packagist version – it’s just a matter of pulling it into the app “the right way”, no?

          But you might be right – to this day I personally still don’t see the point of Symfony Bundles and am wondering if I’ll ever understand them. I’ll have to look into Symfony a bit more to learn about that, I guess.

          • Attila Fulop

            Just a note: I’ve replied to this and that comment’s currently being held by disqus for moderation (guess due to the code blocks within); you may want to release it.

          • Bruno Škvorc

            Weird, I’ll look into that and whitelist you for future comments

  • CrNix

    It certainly has its quirks but I really like Phalcon’s flexibility and great community. You can easily tweak and optimize the code for your needs and it can be adapted to your projects architecture. Sometimes better than with other frameworks.

  • WooDzu

    Are there any benchmarks for PHP7+Phalcon?

  • Attila Fulop

    Killing is an exaggerated word in my opinion. Not to mention the framework’s CPU time is usually very minimal compared to other operations an app does, like db, redis, file, or remote service call operations. So the entire race for better benchmarks is a bit l’art pour l’art.

    Still, big respect to C language based frameworks, and good job ICE Framework ;)

  • johny

    all this “speed” – is a couple of miliseconds in production. nothing especial.

    • how many requests do you say your website has? let’s say your framework takes 150ms (symfony 1|2|3
      style) to render the whole page, you rewrite your app to phalcon, and now it takes 70ms(totally possible), now you are able to serve the double of traffic with the same hardware.
      Maybe if you have 1 viewer, that doesn’t matter, you are right, but when you have a website on production, using phalcon can be the difference between bankruptcy and lucrative business.

      • johny

        now i serve an api (~3-5rps). request done in 70ms-5sec without cache (mostly depends on database and elasticsearch) and 3-15ms with cache.
        the worst situation always with storages, second bad – string/regex and some other native php functions (taking lot of cpu time), all other – is nothing for performance, too little piece.

        • Sounds great in this case, however this is not the situation for all the web.
          Other projects need PHP for what it was made for, just rendering html documents. In this moment I am rewriting an website written in symfony 1.4 and propel orm to phalcon and phql/sql (and the minimum in orm), and the general ratio is 10x-20x faster, in this case cpu usage in both db machine and 5 php slaves is near 100% (4 cores per slave, 8 cores in db). Because php code allocates fragmented chucks of memory and using user defined functions(methods or functions) have a significant penalty in php(and of course, there is no inline functions (explicit as in C, implicit as in JS)) , profiling the app I notice 3 weak spots: autoloading(including include, even with opcode), mallocs, function calls.
          So the conclusion, the more code you move to C and use continuous chucks of allocated memory = the better ;)
          Phalcon loads once per process, the same for your own extensions. PHP code and frameworks, blow your ram once per request ;)

          • johny

            yes, you are right – file system functions like is_file or file_exists in autoloaders are very slow, same for string functions and some native. and all this depends on situation. can’t speak about symfony 1.4, but i think autoloader caching (like in composer with –optimize option) and compilable/cachable templates (like in twig or blade for example) will do the trick. all this template engines uses a lot of string/regex function, that are required a lot of cpu and sometime memory. but i don’t test this on PHP7, maybe it will be better?

          • Are you really comparing an old release of symfony with phalcon? There are so many other factors besides the framework which are affecting the speed in this conversion you’re doing.

    • Peter Masterson

      Actually, that’s far from the case. Most benchmarks are written as simply as possible which doesn’t give phalcon a chance to stretch its legs. I’ve rewritten symphony, zend, and raw Php apps in phalcon, and I gained speed with all three. The symfony app was by far the biggest difference going from 180ms to return the request for the user dashboard down to 35 with phalcon, but I even gained speed over the raw Php app which ws admittedly very poorly written.

  • All good points :)

  • Peter Masterson

    Phalcon is by far my favorite framework. For its quirks, it is by far the most flexible framework that doesn’t corral you into doing things it’s way and just lets you write code how you are comfortable.

  • Eugene Manuilov

    Just in case somebody is still interested in vagrant configuration, I have reworked mine to be much more flexible. Now you can select what database (MySQL, PostgreSQL, MongoDB), caching system (Memcached, Redis), jobs server (Gearman, RabbitMQ) and search engine (Elasticsearch, Sphinxsearch) to use. It has ui interface to activate/deactivate required tools and allows you to create new sites with ability to clone it from private repository. So if you are interested, check it out! :)

  • This is really useful – thank you!

Recommended
Sponsors
Get the latest in PHP, once a week, for free.