As a rather oversimplified rule of thumb, the further a visitor is from your servers, the longer it’ll take to travel “over the wires”. Whilst some websites or web applications target a very specific geographical location - for example a UK-only online store, a US high street chain or a Tokyo transportation hub - the Web is global, which means people can or will access it from over the World. Where are they?Īt some stage in a project, you’ll probably need to decide where your server - or servers - will be physically located. What kind of network connection do they have?Īs well as mobiles generally performing worse than desktop in terms of hardware and network constraints, network connections also vary enormously - not everyone has high-speed fiber-optic based broadband connections, for example. Nevertheless, it’s worth monitoring the extent to which the performance does vary. It probably goes without saying that mobile users often face a very different experience to those on fixed or desktop machines. Are they using a desktop / laptop or a mobile? There are a range of factors which can make a website or application perform differently depending on the user, their device and their circumstances. But first, let’s look at a few things we need to consider. To that end, there are a number of tools you can use. In all likelihood there will be some correlation between the raw data from your server or application and the wait times your user faces - for example, high network latency probably means slow response times and therefore users waiting around for your application to load - it’s always worth seeing your service through their eyes. Whilst a lot of monitoring deals in metrics such as server response times, the amount of available memory or the level your CPU is running at, there’s nothing quite as important as the experience your users are having. Once you have an idea of what can go wrong, you start to get a feel for what to monitor.
#Web application monitoring code
Keeping third-party code or operating system components up-to-date in particular checking for security patches or service packs.Problems with your applications errors and exceptions, inconsistencies in your data or even bugs in your code.Problems with third-party services your S3 bucket is unreachable, your mail provider is experiencing issues, or your CDN has gone down.Component or service failures perhaps your database server has gone down, for example.
Network issues for example a site becoming unreachable, high packet losses, server connections going down or DNS failures.
#Web application monitoring full
At the same time, though, there are a range of things that we can anticipate might go wrong.īroadly speaking, we can divide these issues into a number of categories: The short answer is probably “well, a lot” - and as such, it’s a really tough question to answer definitively. In order to know how and what we should monitor, it helps to have an understanding of what could potentially go wrong. Along the way we’ll be taking a detailed look at Monitis, an all-in-one monitoring platform that is one of the leaders in its field, and how it can help make sure that once you’ve launched your app, it remains running and keeps performing. In this article we’re going to take a look at monitoring, in the context of a website or a web application. Monitoring allows us to be reactive to take action in the event of a problem, as well as proactive taking preventative action before an issue arises. We can plan for failure, have processes in place in the event of a problem arising and even contingencies for a genuine disaster, but in between we can monitor. Thank you for supporting the sponsors who make SitePoint possible.įor better or for worse, our jobs as developers don’t end with that last line of code, the final commit or by hitting the “deploy” button.Įven the best-engineered web application isn’t bullet-proof, the most expensive hosting environments still aren’t one hundred percent reliable and, ultimately, there’s always something that can go wrong.
0 kommentar(er)
