June 10, 2014 at 16:06Phalcon Framework on Production
Recently, the phalcon framework, which is an extension of the language, unusual in the php environment, is gaining popularity. I think that many people are interested in knowing what the framework is in battle, but for one reason or another they cannot afford to use it in development. My company decided on such an adventure and I hasten to share what I saw and felt. Welcome to cat.
The company has a project that requires a dispatcher. Roughly speaking, this is a mechanism for proxying and balancing widgets depending on the user's preference. The current dispatcher inherited roofing felts from the Incas, Aztec roofing felts, which gave rise to the belief within the team that the dispatcher was always without him, too, that with the Earth without the Mayan calendar. In other words, the code is scary, confusing, but it works and requires support. The dispatcher was written on Zend Framework 1, the code is located on Amazon nodes, namely on c3.xlarge, APC is used. At peak loads, it reaches 8-10 thousand hits per minute and at such moments 5 nodes work. This state of affairs did not suit me at all, since the dispatcher itself does not contain complex functionality, working with the database at a primitive level, the results of which are cached, and everything that is possible is cached. The main load is php and Zend. You won’t be able to refuse php, but with the second option you can try, especially since the power manager and the flexibility of the framework were not required at all, and in the first place was the speed of work and resource consumption.
Over the course of the development Phalcon I watched for a long time because its the benchmark , still , and and yet I really liked it and wanted to try something loaded. Well, it was his turn and I whipped up, rewriting the critical dispatcher code on Phalcon, decided to drive it on a test node (m3.medium) with APC. For testing, I used jmeter , created simple load tests and ran them in 500 threads.
Load testing showed that memory consumption was halved compared to Zend. Measured each request with memory_get_usage ().
Since then I did not think that I would write an article, therefore I did not take screenshots of the console and the graphs of Amazon. I will give a comparison in the table:
The results pleased and it was decided to transfer the project to Phalcon. After a little refactoring of the code, implementation of the DI container, the code was tested and ready for production.
I want to emphasize that the code has not been significantly optimized, in many places the code received only cosmetic refactoring. When the time came "Ch" with a sinking heart rolled out a code on the nodes and began to monitor the state of the system. Here is the graph:
What we see: the release was at peak load time - 5 nodes worked on Zend, with a CPU load of 80%. After updating 5 nodes on Phalcon, the load dropped below 20%. The graph shows that there is a return to 5 Zend nodes - this was done in order to make sure that all Zend monitoring graphs coincide with Phalcon. Everything was fine, so I decided to disable the three nodes and see how Phalcon would handle it. Two nodes used a little more than 45% of the CPU, which allowed them to try the adventure and leave one node. The CPU rested at 100% and the 500th error occurred, but the problem was not with Phalcon, but with Nginx, which found it difficult to keep a large number of connections. Immediately I returned one node to the balancer, and set myself the task of twisting Nginx for the future. Replacing Zend with Phalcon allowed us to switch from 5 nodes to 2 nodes, which reduced the cost of Amazon,
I will not describe the framework itself, since the documentation on the site is good, it is in Russian and the purpose of the article is different.
At the time of refactoring, the current version of the framework was 1.2.6, which was used. The framework did not seem crude at all - there were no bugs with the functionality that we needed. I also note that Phalcon knows a lot of things and everything worked in accordance with the documentation.
Used to work with models with built-in Active Record. The models are powerful, they can do a lot of things - validation, caching, communications, virtual foreign keys and so on. For sophisticated queries, there is a meta-language PHQL . For those interested - a link to the documentation.
During development, there were problems with the cache - at some point I noticed that the data is cached very strange, the connection to memcache occurs more than once, there is not always a cache, although the data gets into memcache. The problem turned out to be that I did not correctly use the DI container. I added the cache through the set () method, and when I accessed the DI container, I got a new instance of the class each time, with a new connection to the memcache.
And in order to return the same object every time, you need to put it in a container like this:
After fixing the error, everything worked as expected. This approach allowed us to abandon all Singleton in the project, which was done with pleasure.
After the release, the next version of the framework was released - 1.3, which was installed without problems and worked with the project code. I had to fix only a couple of places with a DI container in order to start the application.
Working with console tasks in Phalcon is quite simple and so far does not have much features, compared, for example, with Zend. There is no way to specify default parameters, and required parameters are required to be added when the task is called directly in the console. Working with parameters comes down to self-parsing.
The upset was the lack of an elementary LogNull in the framework for logging, which had to be added to php.
Also surprised by the lack of ability to merge configs.
UPD: as suggested in the commentary, there is an opportunity .
Of the shortcomings that can be a serious argument for someone to refuse is the inability to fix the code of the framework. If you find a vulnerability, then you can’t do anything with it - the sources are compiled. However, the developers rewrite Phalcon in Zephir (I’ll try to write a separate article about Zephir), which will make it possible to edit the framework itself, as well as write extensions for it for C.
This will be done in the version of Phalcon 2.0, which today has a status of Beta 1. I hope that soon we will see a stable release.
There is something else to tell about the framework, but I think that this is a topic for a separate article, therefore I will summarize briefly the results of using Phalcon on a loaded project:
- performance is not comparable to Zend (similar php frameworks)
- easy to learn if you have experience with frameworks
- the framework does not look raw and unfinished, but there is room to grow and develop
- it is impossible to fix the framework code
Where do the legs grow from
The company has a project that requires a dispatcher. Roughly speaking, this is a mechanism for proxying and balancing widgets depending on the user's preference. The current dispatcher inherited roofing felts from the Incas, Aztec roofing felts, which gave rise to the belief within the team that the dispatcher was always without him, too, that with the Earth without the Mayan calendar. In other words, the code is scary, confusing, but it works and requires support. The dispatcher was written on Zend Framework 1, the code is located on Amazon nodes, namely on c3.xlarge, APC is used. At peak loads, it reaches 8-10 thousand hits per minute and at such moments 5 nodes work. This state of affairs did not suit me at all, since the dispatcher itself does not contain complex functionality, working with the database at a primitive level, the results of which are cached, and everything that is possible is cached. The main load is php and Zend. You won’t be able to refuse php, but with the second option you can try, especially since the power manager and the flexibility of the framework were not required at all, and in the first place was the speed of work and resource consumption.
Over the course of the development Phalcon I watched for a long time because its the benchmark , still , and and yet I really liked it and wanted to try something loaded. Well, it was his turn and I whipped up, rewriting the critical dispatcher code on Phalcon, decided to drive it on a test node (m3.medium) with APC. For testing, I used jmeter , created simple load tests and ran them in 500 threads.
Load testing showed that memory consumption was halved compared to Zend. Measured each request with memory_get_usage ().
Since then I did not think that I would write an article, therefore I did not take screenshots of the console and the graphs of Amazon. I will give a comparison in the table:
| Framework | Threads | Loop | Hits | Max load average | Test runtime | Average response, ms | Median ms | Min ms | Error |
|---|---|---|---|---|---|---|---|---|---|
| Zend | 500 | 60 | 30000 | 125 | 03:30:00 | 3,083 | 2,028 | 271 | 2.83% |
| Phalcon | 500 | 60 | 30000 | 76 | 01:55:00 | 1,549 | 947 | 138 | 0.86% |
Release date
The results pleased and it was decided to transfer the project to Phalcon. After a little refactoring of the code, implementation of the DI container, the code was tested and ready for production.
I want to emphasize that the code has not been significantly optimized, in many places the code received only cosmetic refactoring. When the time came "Ch" with a sinking heart rolled out a code on the nodes and began to monitor the state of the system. Here is the graph:
What we see: the release was at peak load time - 5 nodes worked on Zend, with a CPU load of 80%. After updating 5 nodes on Phalcon, the load dropped below 20%. The graph shows that there is a return to 5 Zend nodes - this was done in order to make sure that all Zend monitoring graphs coincide with Phalcon. Everything was fine, so I decided to disable the three nodes and see how Phalcon would handle it. Two nodes used a little more than 45% of the CPU, which allowed them to try the adventure and leave one node. The CPU rested at 100% and the 500th error occurred, but the problem was not with Phalcon, but with Nginx, which found it difficult to keep a large number of connections. Immediately I returned one node to the balancer, and set myself the task of twisting Nginx for the future. Replacing Zend with Phalcon allowed us to switch from 5 nodes to 2 nodes, which reduced the cost of Amazon,
A few words about the framework itself
I will not describe the framework itself, since the documentation on the site is good, it is in Russian and the purpose of the article is different.
At the time of refactoring, the current version of the framework was 1.2.6, which was used. The framework did not seem crude at all - there were no bugs with the functionality that we needed. I also note that Phalcon knows a lot of things and everything worked in accordance with the documentation.
Used to work with models with built-in Active Record. The models are powerful, they can do a lot of things - validation, caching, communications, virtual foreign keys and so on. For sophisticated queries, there is a meta-language PHQL . For those interested - a link to the documentation.
During development, there were problems with the cache - at some point I noticed that the data is cached very strange, the connection to memcache occurs more than once, there is not always a cache, although the data gets into memcache. The problem turned out to be that I did not correctly use the DI container. I added the cache through the set () method, and when I accessed the DI container, I got a new instance of the class each time, with a new connection to the memcache.
And in order to return the same object every time, you need to put it in a container like this:
$di->setShared('cache', $cacheObject);After fixing the error, everything worked as expected. This approach allowed us to abandon all Singleton in the project, which was done with pleasure.
After the release, the next version of the framework was released - 1.3, which was installed without problems and worked with the project code. I had to fix only a couple of places with a DI container in order to start the application.
Work with CLI
Working with console tasks in Phalcon is quite simple and so far does not have much features, compared, for example, with Zend. There is no way to specify default parameters, and required parameters are required to be added when the task is called directly in the console. Working with parameters comes down to self-parsing.
$argv;There are also no beauties with colored texts, backgrounds, so you can’t decorate the console with a rainbow. But on the other hand, although the functionality is not rich, it nevertheless fulfills its function. And over time, lotions and whistles will appear.Bit of tar
The upset was the lack of an elementary LogNull in the framework for logging, which had to be added to php.
Also surprised by the lack of ability to merge configs.
UPD: as suggested in the commentary, there is an opportunity .
Of the shortcomings that can be a serious argument for someone to refuse is the inability to fix the code of the framework. If you find a vulnerability, then you can’t do anything with it - the sources are compiled. However, the developers rewrite Phalcon in Zephir (I’ll try to write a separate article about Zephir), which will make it possible to edit the framework itself, as well as write extensions for it for C.
This will be done in the version of Phalcon 2.0, which today has a status of Beta 1. I hope that soon we will see a stable release.
There is something else to tell about the framework, but I think that this is a topic for a separate article, therefore I will summarize briefly the results of using Phalcon on a loaded project:
- performance is not comparable to Zend (similar php frameworks)
- easy to learn if you have experience with frameworks
- the framework does not look raw and unfinished, but there is room to grow and develop
- it is impossible to fix the framework code