Often I had to answer, for my self or when others asked me, if the application that I’ve build was able to handle the expected traffic. This is not so difficult to calculate and I’ll try to describe it in this post.
First thing you should do is to understand what the expectations are in terms of traffic and user scenarios. You need to know the scale of your test or how far away you are from the goal. Also, user scenarios will allow you to focus your tests better to the most used areas of the application. For example on a ecommerce application you may want to optimize more on the catalog browsing feature and then less for the checkout process where less users are reaching.
Once you’ve figure out the expectations you need to understand the setup of your production servers. I think is good for every developer to test the performance of it’s application on localhost before commit-ing but this should not be enough. The configuration of all different servers involved can dramatically affect the performance of a website. Also very important would be to remember that adding more resources will not always increase the performance or a website as the performance is not linear . You need to understand the bottlenecks of your website, remember what Donald Knuth said “A list is only as strong as its weakest link.” to discover bottlenecks we need to put the system under stress and then monitor/watch all components.
Ok. Now that we’ve cleared all requirements and we have a basic understanding of the server architecture we should be able to start our testing. The testing section should start be identifing the scenarios we would like to test. Let’s say we want to test a scenario like: 1. browse catalog 2. open product details page 3. add to cart. Once we’ve decided what scenario to test we should run a test with the expected traffic and say maybe it just works and we don’t need to tune anything. (It’s always good to dream as Aristotle said: “Hope is the dream of a waking man.“)
For testing you can use one of the following tools.
If the application performs is time to go out for a beer. If not we should start the test again and this time monitor the activity on the servers to understand where the bottleneck is. This monitoring should not be confused with debugging we are not yet at that step. Turning all debugging on too soon my affect the regular behavior of your system. For monitoring I would use something like vmstat and top to understand how my cpu/memory/disk IO is used and witch one is the bottleneck.
Tipicaly high CPU will mean the application is doing more then it should and I would run a xdebug profile session on the application.
High memory can either mean a bad configured apache server or again the application eating way too much memory.
High disk IO can also mean a missconfiguration on the server (do you have apc enabled? ) or the application behaving strange.
And from this moment on the entire testing process will continue by consecutive fail and try procedures until we get to the metrics set as the goal.
Earlier today Magento announced they’ve been bought by eBay, see http://www.magentocommerce.com/blog/comments/ebay-agrees-to-acquire-magento/.
What does it mean for us the regular Developers working with Magento? Will Magento continue amazing jurney they had already with open source edition? What about enterprise? What about Go?
I bet they will continue to invest and from all the news at Magento Developers Paradise, they will have an amazing Magento 2 release. I can only hope eBay was the one pushing for all improvements in Magento 2 and will continue to believe and invest in this dream and will have a great XCommerce.
I’m waiting for an announcement from eBay on this topic.
And eBay CEO has also announced it.