CakeDC Blog

TIPS, INSIGHTS AND THE LATEST FROM THE EXPERTS BEHIND CAKEPHP

Benchmarking requestAction

Now there has been a lot of discussion in the past few months about requestAction() and how it can very easily create a negative impact on your application. In fact I even wrote such an article myself. However, its high time that someone did the number crunching to really see if requestAction() is actually as slow as we all seem to think it is. So onto the testing method and the results.

Testing method

To test this theory I used a small CakePHP application and the SVN head (revision 8064) of CakePHP. I used a simple sample application with 2 controllers and 2 models. My model method directly returned the results without touching the database, so that database retrieval time and model processing would not be a factor in these tests. As I was only interested in the performance implications inherent in requestAction() itself, I wanted to remove the variance created by connecting to a database. I set debug = 0, and used basic file caching. After warming up the cake core caches, I tested 4 different controller actions.

  • Using Relations / ClassRegistry::init() - The method I originally proposed, and often touted as the 'best' solution to requestAction()
  • Using RequestAction with a string URL
  • Using RequestAction with and Array URL
  • Using a cached RequestAction - This more accurately simulates how we use requestAction at CakeDC.

Benchmarks were generated with Siege I used 10 concurrent users with 110 reps each. My local development web-server is running Apache 2.2/PHP 5.2.6 o n a 2.6GHz Core 2 Duo iMac with 2GB of ram. I ran each test 3 times and took the best result of each.

Using model relations / ClassRegistry::init()

First up was my originally proposed solution of using model relations to access the correct information. I used the following command and got the following results.

siege -b http://localhost/benchmark/posts/using_relations

Transactions:		        1100 hits
Availability:		      100.00 %
Elapsed time:		       63.21 secs
Data transferred:	        1.50 MB
Response time:		        0.55 secs
Transaction rate:	       17.40 trans/sec
Throughput:		        0.02 MB/sec
Concurrency:		        9.60
Successful transactions:        1100
Failed transactions:	           0
Longest transaction:	        1.76
Shortest transaction:	        0.10


Using RequestAction with a string URL

Up next was using request action with a string url. String URL's are often the slower way to perform a requestAction as parsing the URL string is one of the more expensive operations in request dispatching. I used the following command and the best results were.

siege -b http://localhost/benchmark/posts/using_requestaction

Transactions:		        1100 hits
Availability:		      100.00 %
Elapsed time:		       64.60 secs
Data transferred:	        1.51 MB
Response time:		        0.57 secs
Transaction rate:	       17.03 trans/sec
Throughput:		        0.02 MB/sec
Concurrency:		        9.72
Successful transactions:        1100
Failed transactions:	           0
Longest transaction:	        1.76
Shortest transaction:	        0.11


RequestAction with an Array URL

Up next is requestAction() witn an array url. Using an array URL is supposed to expedite the dispatching process as it bypasses much of the parameter parsing done by Router. This theory turned out to be true, as Array URL's clocked in marginally faster than their string counterparts.

siege -b http://localhost/benchmark/posts/using_requestaction_array

Transactions:		        1100 hits
Availability:		      100.00 %
Elapsed time:		       64.08 secs
Data transferred:	        1.53 MB
Response time:		        0.57 secs
Transaction rate:	       17.17 trans/sec
Throughput:		        0.02 MB/sec
Concurrency:		        9.78
Successful transactions:        1100
Failed transactions:	           0
Longest transaction:	        1.66
Shortest transaction:	        0.11

RequestAction using Array URL's and Caching

In my mind this was going to be the most performant requestAction option, due to the cached nature. The results were as expected with this method clocking to be only slightly behind the relation call. It is important to note as well, that this test does not reflect the time savings earned from not having to make an additional query/ round of result parsing. In a real world situation, the savings of using a cached element would be magnified by the cost of the query.

siege -b http://localhost/benchmark/posts/using_cached_requestaction

Transactions:		        1100 hits
Availability:		      100.00 %
Elapsed time:		       63.60 secs
Data transferred:	        1.52 MB
Response time:		        0.56 secs
Transaction rate:	       17.30 trans/sec
Throughput:		        0.02 MB/sec
Concurrency:		        9.62
Successful transactions:        1100
Failed transactions:	           0
Longest transaction:	        1.77
Shortest transaction:	        0.09

Results Summary

In case you quickly scanned through the full results here is a summary of what happened.

Method Requests per second (mean) Total time taken (seconds)
Using relations/ClassRegistry::init() 17.40 63.21
Using requestAction and string urls 17.03 64.60
Using requestAction and array urls 17.17 64.08
Using cached requestaction 17.30 63.60

In closing requestAction() can be slower than a direct method call. There are some benefits to using requestAction though.

  • You have the opportunity to reduce the number of repeated lines of code by putting the requestAction inside the element. In doing so, you create an encapsulated element, that can be included anywhere without having to worry about having the correct method calls in your controller.
  • You can more easily cache the element. By using requestAction in conjunction with element caching you have an easy to use, simple to implement caching. Getting the same results with model method calls in your controller requires additional caching logic in your models.
  • The potential for increased performance. As we saw in the benchmarks above, a cached element performed almost as fast as the direct method call. This margin will grow when a database query is added into the mix.

Now am I retracting my previous stance on requestAction? No, I still feel that there are many situations where requestAction is the incorrect solution and signals poor application design. However, when the need arises it is good to know that requestAction can be as fast or faster than other approaches when implemented properly.

You can download all the files I used for this process and run your own tests as well.

Latest articles

Responsive Websites vs. Native Apps

Do you know what the difference is between responsive websites vs. native apps? With users more and more likely to be browsing your website on their mobiles, have you considered how they see and experience it across devices? A bad mobile experience may be likely to turn potential customers away, so it’s vital to ensuring that all touchpoints match your brand experience and draw customers in. But how do you go about that - what is the best solution for you - responsive website or a native app? Below we look at the differences between the two, however, the best solution for you will be highly dependent on your website and business/consumer needs, be sure to speak with your development team to get the best fit for you! Responsive vs native Responsive Web Design is the methodology that recommends the design and implementation of a website that responds to user behavior and environment based on the screen size, orientation and operating system of their device. While a native/mobile app, once the app has been downloaded, it’s stored directly on their device, so they will be able to access it in every context. Native apps can be used both online and offline. These two mobile solutions do not answer the same needs. In today’s world, all websites should be responsive to mobile devices, but not everyone needs a mobile app. Mobile or native app’s are expensive and time consuming to produce, they also can irritate users who do not see value in downloading them. However, should your product work well or need an app to work well in, you should investigate it. Generally the development time and cost of a native app can make this look like a poor option, however, if your product or need is one of the following, an app is definitely the way to go.

  • interactivity /Gaming is required: an App is the best choice if you require an immersive and interactive user experience.
  • Regular usage and personalization: Are you planning that your users use the app on a regular basis?
  • Complex calculations or reporting: Think banking or financial calculators.
  • Offline accessibility: Is your concept something that you want users to be able to use offline?
A key point to take into consideration when deciding what is the best fit for your business concept, is to keep your goals in  mind. If your goal is purely from a marketing and content distribution consideration, to ensure usability on mobile platforms, then a responsive website is what you need. However, if you are requiring a more immersive brand experience, a native app is required.

Importance of backing up data for small businesses - tips and tricks for you

Data is essential to any business - regardless of the size. And with the recent ransomware attacks, it is important to keep backups regularly. A loss of your business’s data, from a down server or a ransomware attack, can cost a company a lot of money. Types of backups You can either back up online to an out of network cloud server, to a physical storage location or to an offline drive. Either should have you secured from a network attack and will enable you to be up and running after-the-fact. Having a backup strategy cannot be stressed enough, here are some strategies that you could follow:

  1. Cloud backups - keeping data offsite is helpful should you experience a natural disaster.
  2. Encryption of data in transit.
  3. Multiple backups offsite - ensuring 2 or 3 backups are kept.
  4. Testing of backups - ensuring that all backups taken are viable for use should the need arise.
Regular backups can be a life saver - ransomware attacks, natural disasters, corrupt hardware can strike at any moment. Being prepared can save your business money in the long run. Some other tips that you can consider following include
  • Having a file organization standard. Develop a standard way of organizing your files so that you or your users will always know where data belongs.
  • Determine critical files or data. Organize and sort through the files to ensure critical data or files are kept secure and regularly backed-up.
  • Create a local backup solution.
  • Create an offsite backup.
  • Automate your backup procedures.
How do you get started? Its key to create a backup routine, which includes the following information
  • A checklist for the file or data that you need to backup;
  • A backup schedule for times that your backup system will run;
  • Verify the backup to ensure the data is intact.
Also remember, for your website and hosted applications, to check with your local hosting provider as they usually offer backups. For local development work, always use a repository for code and documents, like git, while for binaries, use cloud storage so all you lose, if your hard drive was to crash, is the work of the current day.

With the latest ransomware attack, here’s what you need to know

With the latest attack, Petya, fresh in our minds, we thought it would be a good time to discuss what exactly a ransomware attack is and how you, as a business, can protect yourselves from such. These cybersecurity attacks not only attack individuals and small to medium sized business, but also large multinational enterprises from around the world. What is clear is that the attack from the past week, Petya/GoldenEye while similar, is a lot more serious than the attack of the previous month - the WannaCry worm attack that struck hundreds of thousands of computers.   Have we gotten your attention? Good! The first real way to protect yourself, and your business, is to know what the attacks are and what they look like. And then to move onto how to set yourself up so that you are secured against such an attack. With the latest ransomware worm, the ransomware infects computers and locks down their hard drives. Then demanding $300 ransom in digital currency Bitcoin.
The email account associated with the ransomware will have been blocked, so even if victims pay, they won't get their files back. Many experts are calling for people to not pay the ransom. The virus or worm is spread by infecting multiple computers on a network, and is initially contracted via an outside source, commonly an email. Many companies were hit severely this time round, as they did not update their Microsoft packages, leaving them vulnerable to the attack.  Am I at risk you may be asking yourself? Well potentially. The great news is that if you have a Windows machine, and it is up to date with security updates, then you are fine. The bad news is that if you are on a network with a machine that is not up to date, then this will cause a problem for you should they get the virus. Top tips for keeping you and your network secure:

  1. Keep all servers and network connections up to date with the latest security updates;
  2. Be sure to backup your computer regularly and keeping a recent backup copy off-site.
  3. Brief all network users on what phishing emails look like, the importance of not on links;
  4. Make sure your antivirus software is up to date.

We Bake with CakePHP