1

Sometimes it could be useful for a web application to be able to determine whether a seeming slowness in the application is due to network conditions or something else.

To make it easier to determine the cause in this kind of situation, I was thinking about creating something like a "check the connectivity" client-side script makes e.g. an AJAX call to the server and returns some useful metrics that make it easier to determine if the cause lies with the network.

But how much useful network troubleshooting could be done using a JavaScript that calls the server?

Dee
  • 113
  • 3
  • What could make the network slow if not "*network conditions*"? – Bergi Feb 21 '18 at 04:21
  • You could implement a `/ping` endpoint on your API / site that just returns `true` and log that measurement to some log aggregation tool like Sumo or Splunk. If you get fancy and include where the end-user is geo-located, you would know how well your site performs across the world. – Joseph Feb 21 '18 at 04:23
  • @Bergi, you can read the question again. I highlighted the text that I was referring to in my question: a slowness **_in the application_**. There are more causes to a slowness in a web application than just the network. – Dee Feb 21 '18 at 04:31
  • thanks @JosephSerido, perhaps keeping track of what the "standard return time" is every day (in some server-side table) could be used for reference with what you are saying. Would you mind adding that as an answer? – Dee Feb 21 '18 at 04:34
  • 2
    trying to use ajax to troubleshoot a network is like trying to figure out if lettuce has gone bad by making a salad. if the salad is bad, you'll know when you taste it. eating rotten lettuce is a mistake, not a diagnostic procedure. – I wrestled a bear once. Feb 21 '18 at 04:52
  • @Dee Ah, but I don't write slow applications of course :-) Anyway, just keep timestamps for the activities of your app. Subtract them to find out how long things take. If the overall activity timespans reaches a threshold that you define as "slow", you can check the local process time and the network request time and compare which of them is more likely to be the cause of the sluggishness. Then advise your user to either get a faster device or to get better network service. – Bergi Feb 21 '18 at 05:05
  • somewhat related but not a duplicate: https://stackoverflow.com/questions/1730692/jquery-ajax-how-to-detect-network-connection-error-when-making-ajax-call – SherlockEinstein Feb 21 '18 at 12:43
  • @Bergi, you may not write slow applications but if you have a function on the server that depends e.g. on a connection to a background DB and that connection is slow then your function would be slow in returning. But thank you for the tip, that is much appreciated. – Dee Feb 21 '18 at 13:47
  • @Dee For that, you can also monitor the database connection performance. For example measure the execution time of your serverside processing, and send it with the response, so that when the client experiences an overall long request time you can compare it and show a message like "it's not your connection, the problem is our data center". – Bergi Feb 21 '18 at 19:32

1 Answers1

1

It sounds like you need a way to keep an eye on your site's performance from the end-user's perspective.

One way to do this is to have your client-side scripts include a way to log to a log aggregation site like SumoLogic. Here is a doc to reference about using client-side JavaScript to log to SumoLogic.

On your server side, you could implement a /ping API endpoint that would just immediately return true so you know how long it takes your user to at least reach your site. You can then log to SumoLogic how long that request took. You could do this with other requests as well to see which APIs are slower than others.

If you include geo-location when logging to SumoLogic, you can see how well your site performs around the world.

And if you want to get really fancy, then you should implement a custom header that your APIs understand which is a transaction token of some sort for all requests. When your server receives that header, it should use that token throughout the request's logs so you can see where things go wrong and what to do about them.

Another good site to check out for this sort of thing is New Relic - Browser Monitoring. This is much more performance-centric and you don't get the insights of your own logs, but it's an awesome app in its own right.

EDIT

As mentioned in the comments by @Bergi, you could also have your server respond with the headers immediately and measure performance that way.

Joseph
  • 5,070
  • 1
  • 25
  • 26
  • I don't get the point of making PING requests. Just timing the usual requests that have an actual purpose should be enough. – Bergi Feb 21 '18 at 05:07
  • @Bergi that's a fair point. The reason I suggested `/ping` is because that endpoint should be like a contract that says `I'll respond immediately if I'm 'up'`. This is different than other requests that may have a large payload response or a request that has to process data which can take longer to respond (like a `/getalldata` endpoint that has to query a db and then return when it's finished). If the OP wants to know if the end-user has a good internet connection, then the response from the server should be immediate and a simple `/ping` endpoint can give you that IMO. – Joseph Feb 21 '18 at 05:11
  • Ah ok, but you could still have your server respond with the headers immediately so that you can time that, or even measure its own processing time and include it at the end of the response. Also [getting performance entries](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) can reveal lots of network request details. – Bergi Feb 21 '18 at 05:17
  • @Bergi oh, nice, I didn't realize you could do that. Yeah that definitely works as well :) and thanks for the resource – Joseph Feb 21 '18 at 05:21