We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Performance Comparison between Laravel v4.1 & Phalcon v1.3.1

I wrote up a very small blog post on comparing a Phalcon v1.3.1 project to a Laravel v4.1 project. You can read it here, but I will summerize and possibly go over a few things that were not covered in the post.

I started writing a personal CMS/Blog about a month and a half ago. After getting to a very basic usiblitity stand point, I uploaded to the free teir of OpenShift that I am currently using. And it failed. I am still not 100% sure why and frankly, that is a post for another time. Just about ready to pull my hair out, because of OpenShift, I move the Phalcon code out of the repo and through in a blank Laravel 4.1 install. It worked, so... I went with it. I like Laravel and have used it on another project, but I did not want to use it for this one. But I really had no choice at this point and what you see from the link above is that site.

This past weekend, I decided that I would catch the Phalcon project up to were the Laravel project currently is, plus make sure everything will still work as expected with 1.3.1. So after doing this, I decided to use WebGrind and check out the performance different between to the two projects sitting on my local machine. Reason? I just wanted to know, for one, but also you could actually see a different in how the pages load. I wanted to make sure that I had not messed up some CSS (there's almost no JS libraries in use. Outside of Disqus, which is not intergrated into the Phalcon post views, and Google Analytics which again, is not in any of the Phalcon layouts). Well, here is what I found...

Laravel v4.1

Running a simple query that retrives all of the posts and displays them in orde of their 'id' in a view -

  • Functions Executed : 961 different functions

  • Time to execute : 2050ms

Phalcon v1.3.1

Same as above. Exactly the same

  • Functions Executed : 57 different functions

  • Time to execute : 70ms
Sceenshots are avaliable in the blog post, soo I did not feel a need to duplicate that here.

Now, I knew there was going to be a difference. But I had no idea there was going to be that much difference! My jaw hit the floor when I saw those numbers! So tonight,

Right off we notice a big difference in Time to Execute. This is most likely a reflection of my "cache" at that time or possible my drive was doing something at the time of the first test. Oddly it seems, at first glance, that the weakest link or most expensive is Composers autoloading. I would suspect that trugging through what looks like 36 different files and getting them loaded into the application is quite the task, but no. What is not done justice in the screen shot in my Laravel example screen shoft is that upon reordering the 'Total Inclusive Cost' column, shows that Illuminate\Foundation\Application->run() , Illuminate\Session\Middleware->handle(), as well as Illuminate\Routing\Router->dispatchToRoute takeing up the largest chunk of the chug-a-luggin. All scoring above 50.0. To better display this, I re-ran the tests and found that the Laravel site was actually performing a bit better. Also, I re-orgizined totals a bit to better show what processes were displaying the most cost. What follows is a screen shot of that test...

In our Phalcon example of the app, we can see that similarly to Laravel php::Phalcon\Mvc\Application->handle() is a heavy hitter in the performance catagory, but coming in a fluffy 20.68 just does not compare to Laravels 65.53 TIC (Total Inclusive Cost).

In all fairness, I am not bashing on Laravel just for the sake of bashing on Laravel. Laravel has it's place in the PHP community and will be a big player in the community for a long time to come. I would also expect to see these same numbers from the likes of Symphony or ZendFramework as well. They are all big. They are that way for a reason. But it is Phalcons approach to PHP, as an extention, that single handedly allows it to over shadow the other frameworks out there today, from a performance stand-point. I would really like to see some numbers comparing Laravel 4.1, running on HHVM, and compare those to a pure Phalcon installation. Interesting! Now those numbers might be more in line of what I was actually expecting to begin with.

Again, for the actual code being used in each and more screen shots, check out the blog post linked to at the top of this post. I am currently in the process of getting a Vagrant workflow going that is hooked up to a New Relic account, so I will be performing more in-deth tests at a later time.



9.0k

Wow..... Amazing. Is it really that fast ? Have you try compare it with slim / f3 / CI ? I am very courious.

@byteGator, no I have not. I was thinking about rewriting the app in Slim and maybe Aura, but I don't think I will be doing it in CI anytime soon. I still have lots of things I would like to get working in the current version, before I start another rewrite. I like learning just as much as the next guy, but.... yeah, you know what I mean.

We had a laravel site once, and it was a real dog. We had to use hhvm and witchcraft to get it to perform.

I know the Laravel people say it's cheaper to throw extra hardware at the problem than to waste programmer hours, but it's nicer to use Phalcon, spend the same amount of time developing, and still have something that performs.

The site that we had in Laravel has been converted into Phalcon today. We also made versions in Pixie and CodeIgniter, and Phalcon just blew them all away in AB testing. In the last benchmark we did, Phalcon without no server side caching was still 30% faster than Laravel on HHVM with caching on almost everything.



9.0k

I used to contribute on osclass and have a classifieds site with 7000 unique visitor a day. I am thinking about rewrite my site with Phalcon. But still try to understand how phalcon works.

My advice, is not to worry so much about the "voodoo" on the backside and treat it like any other framework.

But ask yourself the question, "Do I need a MicroFramework or a full MVC?". that will determine how you initialize the app and structure it. In your case, I would probably go MVC. But I am not familiar with your project so...



9.0k

Thanks for your advice. I will go with full MVC.

First time i know phalcon, i thought it is a micro framework that is only suitable to build something like REST API. And in building complex web like classifieds site, using phalcon will not give much performance increase. But looks like Phalcon is more than just micro framework. I can't wait to try it.

Regards Robby

Robby,

What I did in a project I have been working on was to build two applications. One is a web based one (the UI/UX look and feel etc.) and the other one is the API. The Web part doesn't have any models or database integration. It just calls the API for anything it needs.

This way I scale as much as I want, I have options to integrate a mobile app, I can offer API access to other vendors etc.

I wrote the API in micro early enough but then switched it to the full framework because I needed to keep the code neat and tidy (my preference).

You will soon find out that the same hardware with similar code will offer you a lot more performance than before (once you switch to Phalcon that is).

We are here for any questions and help :)



12.1k
edited Apr '14

Did you enable model metadata cache? Because it may save you half of the request time with a simple controller.

Reference: https://docs.phalcon.io/en/latest/reference/models.html#models-meta-data



9.0k
edited Apr '14

Hi Nikolaos

  1. About web based one, are also use phalcon, may for router and other services. Or are you using pure php / ruby for your web.
  2. Is it worth to separate a project using web + api ( where web one call the api one ) when we don't have mobile app and we dont need to have separate database server. Cause VPS is very fast now.

Regards Robby



2.1k

Hi Nikolaos,

I've been working on similar applications as you do too. One is web based and the other one is API. However, the web part doesn't rely on the API, but directly access the same library as the API. This way, I minimized the overhead needed to access the API from the "web app" (network connections, data transfers). Don't you think so?

Cheers,



9.0k

Hi @iman38 and @niden

I think @iman38 way is faster and secure, because it doesn't deal with security problem when the web one communicate with api one. But is it easier to maintain? What do you mean with same library as the API ?

Regards



2.1k

Hi @byteGator,

I replied the mail notification, but it seems that it's not added to the thread. Anyway...

Initially, we only have full stack web app, that is the UI and all the models and library code. Later on, we build the API on top of the same library code since we extend the app to mobile platform and provide access to third parties (and gradually extend the application, both the web and API endpoints).

I'm sorry, I don't clearly understand the question about the easiness of maintaining the code, the 'core' code for both website and API is the same. The difference is that one have full stack web app, and the other one is RESTful style API for external access (technically, the controllers and the views).

Regards,



9.0k

Hi @iman38

So the difference is only on "view" part. Same Models and same controllers.

How do you secure your user registration. We dont have recaptcha here. THen how prevent spammer register a user via API using robots.? I don't know how to solve this, because I use lazy user validation. I don't need a user to validate their email until it really needed.

Regards



9.0k

@niden and @iman38

I make new thread about API here https://forum.phalcon.io/discussion/2043/mvc-ui-web-api-example#C7090.

Please take a look.

REgards

@byteGator

  1. About web based one, are also use phalcon, may for router and other services. Or are you using pure php / ruby for your web.

Everything is in PHP.

  1. Is it worth to separate a project using web + api ( where web one call the api one ) when we don't have mobile app and we dont need to have separate database server. Cause VPS is very fast now.

It is a matter of personal preference. For me it was a decision made based on the fact that I want the application to be scalable with the least amount of money. Beefing up a VPS with more memory and processing power is more expensive than adding a few small VPSs that will handle the API. By separating those layers I can scale as much as I want with the lowest cost possible. Since you don't have a mobile app or are not interested in external integration, it is prudent to keep everything together.

edited Apr '14

I've been working on similar applications as you do too. One is web based and the other one is API. However, the web part doesn't rely on the API, but directly access the same library as the API. This way, I minimized the overhead needed to access the API from the "web app" (network connections, data transfers). Don't you think so?

@iman38

Yes that is a good approach also. It was my personal choice to program it the way I did. I could have used a shared namespace that would keep all the database connectivity/models in it and access that namespace from the API as well as the web part. I opted to just keep all the db stuff in the API. Network traffic is not really a concern if your machines are in the same network. The overhead is negligible.

How do you secure your user registration. We dont have recaptcha here. THen how prevent spammer register a user via API using robots.? I don't know how to solve this, because I use lazy user validation. I don't need a user to validate their email until it really needed.

The API that I wrote is secure, since it uses HMAC authentication. It is nearly impossible for someone to perform a man in the middle attack with that methodology. Since the API and web machines are in the same network, latency is negligible, hence the request from the web to the API is alive for only one second. HMAC allows me also to ensure that I don't keep any complex authentication mechanisms in the API and I can authenticate with whoever has the key. Have a look at this article

https://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

As for the speed, yes traditionally an application that accesses the db directly vs. make a call to the API and get the results back is going to be faster. As I wrote above though, network latency is negligible and my benefit is cheap scalability.



2.1k

@niden,

+1 for HMAC And make sense for the reason of your app architecture.

edited Apr '14

If anyone is interested, I posted a Part 2 to the blog post mentioned in my intial post. it covers performance enhancements to both versions using the command 'composer dump-autoload --optimize'. Next, I will be taking @Viktoras suggestion and compare caching performance gains and implementation between both versions of the app. NICE!

Then on to HHVM, because Vagrant likes me pretty well, but Puppet and Protobox are kicking my backside.

So, I finally got a working HHVM install up and running inside a Vagrant box. But I am running into one little issue and without redoing the frontend of the site, I will not be able to test the site on HHVM. So the tests might take a bit longer to get around to.

Whats holding me up? I am using inline SVG's on my site for some icons. And this is causing HHVM to scream at me. What do inline SVG's have to do with HHVM or PHP or anything at all for that matter?

First, let's take a look at the error I retrieved from the error log:


\nFatal error: syntax error, unexpected T_STRING in /vagrant/blog/web/app/storage/views/4143... on line 46

Well, to explain a little further, let me show you a sample svg I am using for an email icon.

<?xml version="1.0" encoding="utf-8"?>
    <!-- Generated by IcoMoon.io -->
        <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
            <svg version="1.1" xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" width="32" height="32" viewBox="0 0 32 32">
                <g></g>
                <path d="M26.667 0h-21.333c-2.934 0-5.334 2.4-5.334 5.334v21.332c0 2.936 2.4 5.334 5.334 5.334h21.333c2.934 0 5.333-2.398 5.333-5.334v-21.332c0-2.934-2.399-5.334-5.333-5.334zM5.707 27.707l-2.414-2.414 8-8 0.914 0.914-6.5 9.5zM4.793 6.207l0.914-0.914 10.293 8.293 10.293-8.293 0.914 0.914-11.207 13.207-11.207-13.207zM26.293 27.707l-6.5-9.5 0.914-0.914 8 8-2.414 2.414z" fill="#000000" class="mail"/>
            </svg>

As you can see, the code starts out with <? , which is the same as PHP or Hack. THis is actually what is on line 46 of the file view in question. The only way that I can see working around this, will be to remove the inline SVG and replace the inline usage with an <object> element. This way, I can retain the ability to control the SVG with css, so... I had some issues with this, when I first did the design several months ago. Guess I will have to revisit it tackle it this time. Then I can move forward with the tests.

Well, I was able to run some quick tests tonight using Chrome DevTools and it shows that the Laravel version of the blog is seeing roughly a 50% increase in performance. And that is great. No, it's great! 50% is awesome! But, it still does not bring it even close to the performance of the same blog written in Phalcon.

As of right now, given the latest numbers Phalcon - ~74ms(running on plain apache 2.2, no nginx) Laravel - ~268ms(running hhvm v3.1 and nginx. No PHP installed!)

I still have some more tests. Since I am running Vagrant now and got that puppy whooped, I feel I need to test Phalcon on plain Nginx. Not expected to see a big increase, but feel like it should be done. Sorta starting to get burnt out on building enviroments over and over, but... well, I'm learning a ton, so I guess I shouldn't complian. Anyway, looking to put together another blog post with all the info and build process for HHVM and the above troubles I mentioned with "inline SVG's" and hoping to have that done by this weekend.

Until then.. Fly with Phalcon!

I'm deciding if I should go with Phalcon or Laravel 4. Reading your test results I'm wondering if you configured vagrant correctly to run laravel 4. When I tested laravel for the first time it was also slow (a few seconds out of the box) . This seems to be caused by the way varant syncs it's folders:

https://stackoverflow.com/questions/23283574/is-laravel-really-this-slow

I would like to see you run the test again, and see if you get the same results.

Well, I was able to run some quick tests tonight using Chrome DevTools and it shows that the Laravel version of the blog is seeing roughly a 50% increase in performance. And that is great. No, it's great! 50% is awesome! But, it still does not bring it even close to the performance of the same blog written in Phalcon.

As of right now, given the latest numbers Phalcon - ~74ms(running on plain apache 2.2, no nginx) Laravel - ~268ms(running hhvm v3.1 and nginx. No PHP installed!)

I still have some more tests. Since I am running Vagrant now and got that puppy whooped, I feel I need to test Phalcon on plain Nginx. Not expected to see a big increase, but feel like it should be done. Sorta starting to get burnt out on building enviroments over and over, but... well, I'm learning a ton, so I guess I shouldn't complian. Anyway, looking to put together another blog post with all the info and build process for HHVM and the above troubles I mentioned with "inline SVG's" and hoping to have that done by this weekend.

Until then.. Fly with Phalcon!

Laravel is good for prototyping only.!! :3