Phalcon Framework in production
In recent times, the phalcon framework, which is an extension of the language, is gaining popularity. I think that many people are interested in finding out what the framework is in a battle, but for one reason or another they cannot afford to use it in development. In my company, they decided to make such an adventure, and I hasten to share what I saw and felt. Welcome under cat.
The company has a project for which a dispatcher is required. Roughly speaking, this is a mechanism for proxying and balancing widgets, depending on the user's preference. The current dispatcher inherited felts from the Incas, felts of the Aztecs, which gave rise within the collective to the belief that the dispatcher was always without him, too, that with the Earth without the Mayan calendar. In other words, the code is scary, confused, but it works and requires support. The dispatcher is written on Zend Framework 1, the code is located on the Amazon nodes, namely on c3.xlarge, APC is used. With 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 himself does not contain complex functionality, working with the database at a primitive level, the results of which are cached, and everything that can be done is added to the cache. The main load is php and Zend. Php will not be rejected, but with the second option you can try, all the more so for the dispatcher of power and flexibility of the framework was not required at all, and in the first place was the speed and resource consumption.
I followed the development of Phalcon for a long time, because its benchmark was still , and I also really liked it and wanted to try it in something loaded. Well, it was his turn and I quickly, rewriting the critical code of the dispatcher on Phalcon, decided to drive it on the test node (m3.medium) with the 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. Measure each request with memory_get_usage ().
')
Since then I did not think that I would write an article, so I did not take screenshots of the console and Amazon charts. 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, the implementation of the DI container code was tested and ready for production.
I want to emphasize that the code was not significantly optimized, in many places the code received only cosmetic refactoring. When the time came "H" with a sinking heart rolled out the code on nodes and began to monitor the state of the system. Here is the schedule:
What we see: the release was at peak load time - 5 nodes worked on Zend, with CPU load at 80%. After updating the 5 nodes on Phalcon, the load fell below 20%. The graph shows that there is a return to 5 Zend nodes - this was done to make sure that all Zend monitoring schedules coincide with Phalcon. Everything was fine, so I decided to turn off the three nodes and see how Phalcon will cope. Two nodes used a little more than 45% of the CPU, which made it possible to try the adventure and leave one node. CPU rested on 100% and the 500th error went, but the problem was not with Phalcon, but with Nginx, which was hard to keep a large number of connections. Immediately I returned one node to the balancer, and set myself a task for the future to tweak Nginx. Replacing Zend with Phalcon made it possible to switch from 5 nodes to 2 nodes, which lowered spending on Amazon, and also helped deploy and monitor the system.
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 didn’t seem raw at all - no bugs with the functionality that we needed were noticed. Also note that Phalcon can do quite a lot of things and everything worked in accordance with the documentation.
Used to work with models with built-in Active Record. Models are powerful, they can do a lot of things - validation, caching, connections, virtual foreign keys and so on. For sophisticated queries, there is a PHQL meta-language. For those interested - a link to the documentation.
During development, there were problems with the cache - at some point I noticed that data is very strangely cached, there is a connection with memcache more than once, there is not always a cache, although there is data in memcache. The problem was that I didn’t use the DI container correctly. I added the cache via the set () method, and when accessing the DI container each time I received a new instance of the class, with a new connection to the memkes.
And in order to return the same object every time, you need to put it in a container like this:
Correcting the error, everything worked as expected. This approach allowed to abandon all Singleton in the project, which was done with pleasure.
After the release, the next version of the framework, 1.3, was released, which was installed and worked without problems with the project code. I had to fix only a couple of places with a DI container to start the application.
Working with console tasks in Phalcon is quite simple and so far has no great potential compared to, for example, Zend. It is not possible to specify the default settings, and mandatory - ask to add when you call the task right in the console. Working with parameters is reduced to an independent parsing
Upset the lack of an elementary LogNull in the framework for logging, which had to be added to php.
Also surprised by the lack of opportunity merdzhit configs.
UPD: as suggested in the comments - the possibility is
Of the shortcomings that can be a serious argument for someone to refuse is the inability to correct the code of the framework. If you find a vulnerability, you can’t do anything about it - the sources are compiled. However, the developers rewrite Phalcon to Zephir (I’ll try to write a separate article in more detail about Zephir), which will make it possible to edit the framework itself, as well as write extensions to it for C.
This will be done in the version of Phalcon 2.0, which today has the 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 in brief the result of using it on a loaded Phalcon project:
- performance is not comparable with Zend (similar to php frameworks)
- easy to learn if you have experience with frameworks
- the framework does not look raw and unfinished, however there is much to grow and develop
- it is impossible to fix the code of the framework
Where the legs grow
The company has a project for which a dispatcher is required. Roughly speaking, this is a mechanism for proxying and balancing widgets, depending on the user's preference. The current dispatcher inherited felts from the Incas, felts of the Aztecs, which gave rise within the collective to the belief that the dispatcher was always without him, too, that with the Earth without the Mayan calendar. In other words, the code is scary, confused, but it works and requires support. The dispatcher is written on Zend Framework 1, the code is located on the Amazon nodes, namely on c3.xlarge, APC is used. With 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 himself does not contain complex functionality, working with the database at a primitive level, the results of which are cached, and everything that can be done is added to the cache. The main load is php and Zend. Php will not be rejected, but with the second option you can try, all the more so for the dispatcher of power and flexibility of the framework was not required at all, and in the first place was the speed and resource consumption.
I followed the development of Phalcon for a long time, because its benchmark was still , and I also really liked it and wanted to try it in something loaded. Well, it was his turn and I quickly, rewriting the critical code of the dispatcher on Phalcon, decided to drive it on the test node (m3.medium) with the 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. Measure each request with memory_get_usage ().
')
Since then I did not think that I would write an article, so I did not take screenshots of the console and Amazon charts. 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 | 30,000 | 125 | 03:30:00 | 3,083 | 2,028 | 271 | 2.83% |
| Phalcon | 500 | 60 | 30,000 | 76 | 01:55:00 | 1.549 | 947 | 138 | 0.86% |
Release
The results pleased and it was decided to transfer the project to Phalcon. After a little refactoring of the code, the implementation of the DI container code was tested and ready for production.
I want to emphasize that the code was not significantly optimized, in many places the code received only cosmetic refactoring. When the time came "H" with a sinking heart rolled out the code on nodes and began to monitor the state of the system. Here is the schedule:
What we see: the release was at peak load time - 5 nodes worked on Zend, with CPU load at 80%. After updating the 5 nodes on Phalcon, the load fell below 20%. The graph shows that there is a return to 5 Zend nodes - this was done to make sure that all Zend monitoring schedules coincide with Phalcon. Everything was fine, so I decided to turn off the three nodes and see how Phalcon will cope. Two nodes used a little more than 45% of the CPU, which made it possible to try the adventure and leave one node. CPU rested on 100% and the 500th error went, but the problem was not with Phalcon, but with Nginx, which was hard to keep a large number of connections. Immediately I returned one node to the balancer, and set myself a task for the future to tweak Nginx. Replacing Zend with Phalcon made it possible to switch from 5 nodes to 2 nodes, which lowered spending on Amazon, and also helped deploy and monitor the system.
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 didn’t seem raw at all - no bugs with the functionality that we needed were noticed. Also note that Phalcon can do quite a lot of things and everything worked in accordance with the documentation.
Used to work with models with built-in Active Record. Models are powerful, they can do a lot of things - validation, caching, connections, virtual foreign keys and so on. For sophisticated queries, there is a PHQL meta-language. For those interested - a link to the documentation.
During development, there were problems with the cache - at some point I noticed that data is very strangely cached, there is a connection with memcache more than once, there is not always a cache, although there is data in memcache. The problem was that I didn’t use the DI container correctly. I added the cache via the set () method, and when accessing the DI container each time I received a new instance of the class, with a new connection to the memkes.
And in order to return the same object every time, you need to put it in a container like this:
$di->setShared('cache', $cacheObject);Correcting the error, everything worked as expected. This approach allowed to abandon all Singleton in the project, which was done with pleasure.
After the release, the next version of the framework, 1.3, was released, which was installed and worked without problems with the project code. I had to fix only a couple of places with a DI container to start the application.
Working with CLI
Working with console tasks in Phalcon is quite simple and so far has no great potential compared to, for example, Zend. It is not possible to specify the default settings, and mandatory - ask to add when you call the task right in the console. Working with parameters is reduced to an independent parsing
$argv; Also, there are no beautiful with color texts, backgrounds, so that decorate the console with a rainbow will not work. But on the other hand, although the functionality is not rich, it still performs its function. And over time, there will be gadgets and whistles.A little bit of tar
Upset the lack of an elementary LogNull in the framework for logging, which had to be added to php.
Also surprised by the lack of opportunity merdzhit configs.
UPD: as suggested in the comments - the possibility is
Of the shortcomings that can be a serious argument for someone to refuse is the inability to correct the code of the framework. If you find a vulnerability, you can’t do anything about it - the sources are compiled. However, the developers rewrite Phalcon to Zephir (I’ll try to write a separate article in more detail about Zephir), which will make it possible to edit the framework itself, as well as write extensions to it for C.
This will be done in the version of Phalcon 2.0, which today has the 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 in brief the result of using it on a loaded Phalcon project:
- performance is not comparable with Zend (similar to php frameworks)
- easy to learn if you have experience with frameworks
- the framework does not look raw and unfinished, however there is much to grow and develop
- it is impossible to fix the code of the framework
Source: https://habr.com/ru/post/225851/
All Articles