By Darren Beale

If you’re a non-technical manager of a web software application, it can be hard to wrap your head around such things as:

  • How your application is actually being used
  • How to recognize performance issues
  • How to best address performance issues

This is especially true if you are relying on a third-party development or maintenance team.

Making choices as a manager involves understanding the trade-off between the cost of minimizing performance issues and the financial benefits of doing that. Another factor can be the possible future consequences of not thinking ahead and optimizing the system now.

At Siftware, we’ve worked with clients large and small on a diverse array of web applications. In this article , we’ll give you some high-level thoughts on how you can gain a better understanding on performance and usage issues, and how you might improve them.

Overview of Web App Performance Problems

Most performance issues are, at heart, user experience issues. And most of these boil down to response time: basically, pages or results taking too long to load. Excessive load times frustrate users, and that’s the main issue app companies want to minimize.
Most applications are complex systems. Too-long response times can be due to any number of factors or combination of factors, such as:

  • Unavailable servers
  • Insufficient number of servers
  • Unexpected spike in user traffic
  • Inefficient code
  • Delays from third-party APIs

While trying to address these issues, app companies want to use their resources efficiently. In a perfect world, we all want 100% availability for our app and zero-second response time. That is impossible to achieve, but the more a company is willing to spend, the closer they can get to that theoretical goal.
So the hard choices for any app management team are in deciding where those trade-offs occur. How much money and effort do we put into making our app as fast and available as possible?

In short, how good is good enough?

How Good Is Good Enough?

“How good is good enough?” can be difficult to answer. It will be a judgement call based on the specific business needs of your company. It will be a cost-benefit analysis to determine the costs of optimizing the app and the financial benefits of doing that work.
Some questions that come into play in determining this:

  • What is the estimated cost to the company of the app being down for x amount of time?
  • What is the estimated cost of losing one user/visitor due to slow response time?
  • What is the estimated upside to having very high availability?
  • What is the potential upside to having a super-fast response time?

These are obviously hard things to estimate and weigh, as there are usually many unknowns. But basically you are trying to determine how important your app is to your business and in what ways it is important. The more clear you get on how much your app matters to your company, the better you’ll be able to come up with your performance requirements.

Setting Performance Requirements

Your app’s performance requirements will be whatever you’ve decided are the most important metrics your app needs to achieve. App performance requirements can be things like:

  • Average page load (from a user perspective) must be less than 500 milliseconds.
  • Slowest page load cannot take more than 4 seconds.
  • The app must be available more than 99.5% of the time, on average.
  • The app must be available more than 99.999% of the time during the hours of 8am-6pm EST.

Sometimes these requirements will be highly specialized based on your needs. For example, a financial transaction app will often need to be as instantaneous as possible, whereas a dating app will have much less need for immediate response time.
There’s a good chance your company (or development team) already has such requirements in place, but if not, you will want to set them in place. Without performance requirements, there’s no way to measure the performance of the app and to tell your team where to direct its attention.

Benchmarking, Monitoring, and Profiling

There are a few processes and terms you should be familiar with that are part of the app analysis and optimization process. Here are some of the major ones:

Benchmarking. Benchmarking refers to running load tests on your app to see how it responds. This gives you a concrete, scientific way to test its speed and response time. Without benchmarking an app and having those objective numbers, it is hard to tell if future code changes actually improve or hurt the app.

Monitoring. Monitoring usually refers to the real-time tracking of stats from a server, a network, or an app. Monitors can track simple things, like the response time on a server or the availability of a network, or more in-depth things, like end-user experience and error rates.

Profiling. Profiling refers specifically to running tests on the structure of the code itself to check for potential problems of inefficiency or bottlenecking.
The various analysis and monitoring tools on the market overlap in function a bit. Here are some of the popular ones:

  • Pingdom Pingdom is an availability monitoring and alerting solution.
  • Nagios Nagios is a well-known IT infrastructure (servers and networks) monitoring and alerting app.
  • Datadog Datadog tracks everything from network devices to app functions.
  • New Relic New Relic monitors application performance and has browser developer tools and server monitoring tools.
  • Siege Siege is an open-source load-testing and benchmarking utility.
  • Xdebug Xdebug is an open-source debugger for PHP that can also be used for profiling.

Most of the commercial systems above have a free trial version that gives you a certain number of devices you can monitor for free, with paid versions for higher usage.
When you have decided on your performance requirements, you can use such app analysis and monitoring tools to figure out where exactly the current problems with your app are stemming from.

For example, a monitoring tool might tell you that there is occasionally an excessive delay stemming from a specific third-party API call. Or you might see that 20% of visitors (potential customers) are exiting a specific page before continuing, and that loss seems to be due to a specific type of database call.

With load testing and profiling, you can also get a sense of where future problems, stemming from higher traffic and more users, might show up.

You can use some of these systems to set alerts and notifications based on your requirements. For example, if one of your requirements is that there be at least 20 cloud servers available at any one time, then you can set an alert that notifies you if the availability falls below that, or to maybe take some other proactive action.
With the improved understanding of the app possible with these analysis tools, you can continually work to erase existing problems and problems that pop up. This is all a part of the continual improvement process.

App Maintenance Is A Business Cost

In a nutshell, the more business-critical your app is, the more money you will probably need to spend on it, to make sure it’s continually kept up to date, available, and running smoothly. If you decide your software application isn’t that business-critical, you may decide you don’t need that much maintenance or continuing work.

For most commercial apps, though, it’s important to understand that apps are like every other part of the business: they have associated business costs. Some people seem to believe that an application should be a build-it-and-forget-it, one-time cost—that once it’s created, it will just keep operating at peak performance and require no further input or maintenance. That doesn’t work with your car (or really anything else in life), and it doesn’t work with modern apps.

But for most business structures, there are associated costs. It’s no different for an application. The ongoing costs with apps come from:

Technology changes. Third-party dependencies (programs your app needs to function) may disappear or become outdated. There may be new and better solutions that are deemed necessary to use. Generally, the longer an app goes without being updated, the more difficult it becomes to update later. This is particularly true if the app was coded using a particular framework or if the server that the app sits on is left unpatched for months or years. It can then become very difficult to move or upgrade as the dependency tree becomes more and more complex.

Scaling. As the usage of your web app grows, there may be unforeseen user-experience or resource problems that require attention.
Like most business structures, the more important the structure is to your business, often the more you have to pay to make sure it’s functioning well. This is an important perspective to have when it comes to managing an app.

Problems of High Traffic

Some problems of scaling can be foreseen and planned for. (This is where load testing and profiling an app come into play.) Some companies will skimp on this stage, simply because it may seem an unnecessary expense and they may be thinking something like, “We’ll cross that bridge when we come to it.” For some simple web apps that are not business-critical, this may be an appropriate response. But for large, complex and business-critical apps, it is probably better to think about those scaling issues upfront, when it is easier and less costly to think about and fix those issues.

We’ve had some clients where scalability was an issue—where we told them, “Your app works now, but it’ll be a real issue if it starts getting 10 times the traffic,” or “Your app works now, but it’ll be a problem if it gets a sudden spike in traffic.”

Clients faced with that problem sometimes jokingly say something like, “Wouldn’t that be a nice problem to have?” And sometimes the problem isn’t addressed because they don’t want to deal with it at that point in time. And then, when those clients DO get that increase in traffic, it’s not a nice problem to have any more. In fact, it’s often a real and expensive pain.

So the moral is that you should think about issues of scalability and user increase. There is no one-size-fits-all answer, but you will have to weigh a few factors to reach a decision that’s right for you.

Once you’ve decided on your performance requirements, there are many app tools you can use to work toward your requirements.

Ask Questions

Chances are the dev team you’re working with (whether internal or external) is already using these systems. If they’re *not* using such systems, you should definitely make it a point to institute such monitoring.

If you aren’t doing so already, reach out to the PHP development team and ask them about:

  1. What they’re monitoring
  2. How they’re using that data
  3. What their ideas are for areas of improvement

If you want to really be “in the loop”, maybe ask your team to set up an account for you on some of these monitoring platforms so you can get a concrete, hands-on sense of how the app is doing.

Summary

In this article we’ve helped you get more clear on understanding ways of measuring app performance and usage metrics, and how to go about improving those app aspects. It is admittedly a hard subject to talk about, as there are so many factors, but we hope this was a good primer and starting point.

We hope you’ve enjoyed our series of content. Let us know your thoughts and feedback—we’d love to hear from you.

And if You Need Help…

If you ever need any help or advice regarding the support and management of your PHP application, please feel free to reach out and ask us for an opinion.

We’re Siftware.

Our service offering is laser focused and we only work with owners or managers of existing PHP applications. If you would like to find out how we can help you please don’t hesitate to book a free consultation.