Considering we don’t have the luxury of unlimited funds, we’ve already accepted the possibility of occasionally degraded performance or even unavailability. If performance degrades too much, we always have a way out by scaling up, increasing the size of the box. This is easy, so we have the opportunity to push our luck a bit. We can try to find the real limits of our small infrastructure by being deprived of resources, and we’ll only scale up when we really have no other option. By then, we will probably be ready to start planning for some elasticity in our infrastructure.
There are two types of performance measurements: absolute and relative. We think that measuring absolute performance is only necessary for something like management software for a nuclear power plant. So, most of the time, we are more interested in relative performance.
In Internet apps (web, mobile, etc.), there are always two sides to performance: the client side and the server side. You can help the client by using CloudFront, for example. For the rest, it basically comes down to using the checklists provided by excellent tools like FireBug or the developer tools in Chrome. On the server side, however, we can help a lot. If your server is not too busy, performance is usually OK (if you followed the checklists, of course). But if your server is getting busier, performance can degrade quickly.
It is relatively easy to test this kind of performance. With tools like Apache ...