Server ping tests

Bloke · 2011-11-23 17:03:27

Just as a quick heads-up, there’s a little plugin in beta called smd_ping. It’s handy as a prelude for remote access to services to test if that service is available, or if it responds quick enough to meet your demands.

You can give the plugin a list of hosts if you like and it’ll try them in order (or optionally shuffled randomly) until it finds one that meets your requirements. Any server that has too much packet loss, or whose Time To Live / Round Trip Time is too great is ignored.

As soon as a suitable candidate server is found from the list, the form/container is executed with the matching server credentials and statistics (average TTL / RTT / packet loss percentage) available so you can take action on that server: connect to it, offer a download, fetch a feed, whatever.

The plugin supports <txp:else /> so in the event none of the servers match your stringent requirements you can tell someone about it or offer Abort Retry Fail options.

Please consider giving it a spin and let me know how it works out. I’m especially interested if it detects the ping command correctly on different hosts / OSs or if you need to consistently override it with the pingcmd attribute. Also, I’d like to know whether it captures the output properly. Each system seems to display different information so the rudimentary screen scraping regex technique used to parse the output might not be generic enough for all flavours of ping out there in the wild. If you find it’s not working, please add the debug="2" attribute to the plugin then post what you see and let me know what OS/host environment you are running so I can try and catch them all.

Many thanks in advance.

ruud · 2011-11-24 19:12:12

A few comments.

TTL is not measured in ms. What you see is the default TTL provided by the sender (the host you’re testing) minus the number of hops in the path from the sender to you. The default TTL can vary per host, so if you’re just using ping, it doesn’t really provide any indication about the quality of the connection to the host. Unless the route back to you changes during the test, you won’t see any variation in TTL.

Some hosts block ICMP echo requests (ping on Windows) or UDP (ping on Linux), so you won’t get a response even though the target host is available. If the aim is to test a specific service (HTTP, probably), you may want to do an actual HTTP connect instead to test response time. Added bonus is that you’re not just testing network lag, but also the response time of the service on the webhost (on a server with high load levels, the ping response time can be low, while the actual service responds much slower).

maruchan · 2011-11-24 22:10:11

Fascinating, ruud. I was wondering about HTTP vs. ping, thinking about some sort of site monitoring panel for my own TXP dashboard.

btw Stef: Sean Connery version:
<txp:eshmd_one_ping_only />

Last edited by maruchan (2011-11-24 22:10:26)

Bloke · 2011-11-24 23:09:52

ruud wrote:

TTL is not measured in ms.

My bad, thanks for the clarification.

Some hosts block ICMP echo requests

Yes, that’s one reason I haven’t pursued this plugin any further, because of the frailties of ping and the fact it’s different across hosts and has a different response dependent on server environment. I just found this function lurking inside the long lost (unreleased) next version of smd_remote_file that I started about 3 years ago and thought the concept of a generic “is server up before I do X” would work better as a standalone plugin, but…

you may want to do an actual HTTP connect instead

… you are of course right. I could just curl a web page (or use fsockopen as fallback). I’ve traditionally used that to fetch whole web pages or feeds, which is probably why I glossed over its ability to just test a connection at the host level without fetching anything. I’ll RTFM and investigate a better system to do this than ping. Not sure how I’ll test response time though. I guess microtime() might help but I’m not sure if socket requests operate asynchronously or if multi-threaded environments make any difference. Will read up.

Many thanks for giving me a kick in the right direction.

Last edited by Bloke (2011-11-24 23:12:41)

merz1 · 2011-11-25 12:47:36

The ICMP messages are exactly the right way to check for an existing route to a server. The server mustn’t answer but the gateway should.

You should always try to get the first correct answer from the server by using the protocol standards. Edit: Well, I should be more verbose: Do a telnet, read the answer and react appropriately. Be warned: Attentive admins will register such tries as port attack depending on frequency and bias :)

Fetching a file eg the favicon.ico or the robot.txt is OK but not certain depending on proxy configuration, caching, load balancer, delivery network etc.

Last edited by merz1 (2011-11-25 13:04:03)

ruud · 2011-11-25 17:23:07

merz1 wrote:

The ICMP messages are exactly the right way to check for an existing route to a server. The server mustn’t answer but the gateway should.

Right, they’re perfect for that purpose… but not for checking if a service running on that server responds quickly. Ping might show fast, reliable responses, while the actual service (like HTTP) is not running and the opposite can happen as well.

I wasn’t talking about a “no route to host” problem, but about a host that simply drops ICMP echo request packets. In that case, the gateway won’t sent an ICMP message back.

merz1 · 2011-11-25 17:57:00

ruud wrote:

I wasn’t talking about a “no route to host” problem, but about a host that simply drops ICMP echo request packets. In that case, the gateway won’t sent an ICMP message back.

Yes, that’s why route and protocol checking needs some know-how. If the server doesn’t respond to ICMP directly a traceroute will show the latest responding point. I wasn’t talking about an “automatic” answer mechanism which will kick in if the server drops ICMP packages.

As I said it might be OK to check the protocol answer on a certain server port from time to time but please don’t do it with every page impression.

Bloke · 2011-11-25 19:50:34

merz1 wrote:

OK to check the protocol answer on a certain server port from time to time but please don’t do it with every page impression.

Right. I’m actually not even sure if this plugin is a good idea at all. It formed part of smd_remote_file because that uses a load balancing system to choose from one of the available servers to return your file_download. In v0.4 it just blindly (randomly) chose one of the available locations to serve the file from.

It occurred to me that at any one time, a download provider — e.g. FileDen — might be down for whatever reason or be having a go-slow. In that case it’d be handy to serve the file from one of your alternate locations to avoid excessive delays or timeouts (= a better user experience).

Under those conditions, it is important to ask the server immediately prior to the download: “Are you there?” and if it doesn’t respond within a suitable time frame, move onto the next one, and the next, until you find one that responds favourably.

But if you’re using the plugin to test for a static service/feed — one that is more than likely going to be there — then either:

a) the plugin could cache the results for N time period to avoid excessive traffic — at the expense of a false result every now and then
b) you won’t bother using the plugin at all because you trust the remote source to be up

So perhaps there really is no need for this plugin outside the realm of smd_remote_file and I should just quietly slink away and fold it back into that plugin, then forget this topic existed.

Is there any need for it as a general purpose tool?

Last edited by Bloke (2011-11-25 19:52:32)

ruud · 2011-11-26 15:33:06

If you’re fetching remote content, why check in advance if the server is up. Instead just set a read timeout in the command used to fetch the content. If it times out, switch to a different server. Saves 1 connection. Checking separately in advance takes extra time.

Gocom · 2011-11-26 19:29:43

ruud wrote:

If you’re fetching remote content, why check in advance if the server is up. Instead just set a read timeout in the command used to fetch the content. If it times out, switch to a different server. Saves 1 connection. Checking separately in advance takes extra time.

This.

Bloke wrote:

Is there any need for it as a general purpose tool?

Outside of “Is it down?” service, can’t really think any good reason to have such functionality as a tag(?). But my brain is a sandbag.

Bloke · 2011-11-26 21:00:21

ruud wrote:

set a read timeout in the command used to fetch the content

Yes, I’ve used that before and it works on most connections, but if it’s set too low — say a second or two — then the server tends to always “time out” if you/server are on a slow connection or if the packets take a long route. Any longer — the default 10 seconds — and you sit there twiddling your thumbs, then might find the server times out anyway and have to move onto the next — with 4 servers that’s 30+ seconds wait, which is excessive. A pre-emptive quick ping (of some form) to say “which one of you is quickest” before doing the actual connection saves time in some cases at the expense of an extra connection.

Things get more heated when connecting via SOAP, which doesn’t seem to honour the concept of a timeout. At least, I’ve seen it mentioned somewhere but it never actually seems to respond under timeout conditions, it just tries and tries and tries until the usual socket/network timeout kicks in after 30 or 60 seconds. In these cases a standard ping test is useless too, since the server might be there but the WDSL might not be available, which destroys anything else down the line.

SOAP aside, perhaps I just need to get smarter at load balancing and doing things better. Then maybe I can use connection timeouts to my advantage and drop this idea for good.

Thanks for all your input so far. Looks like this one is going to be axed. No great loss.

Last edited by Bloke (2011-11-26 21:02:07)

Textpattern CMS

Textpattern CMS support forum

#1 2011-11-23 17:03:27

Server ping tests

#2 2011-11-24 19:12:12

Re: Server ping tests

#3 2011-11-24 22:10:11

Re: Server ping tests

#4 2011-11-24 23:09:52

Re: Server ping tests

#5 2011-11-25 12:47:36

Re: Server ping tests

#6 2011-11-25 17:23:07

Re: Server ping tests

#7 2011-11-25 17:57:00

Re: Server ping tests

#8 2011-11-25 19:50:34

Re: Server ping tests

#9 2011-11-26 15:33:06

Re: Server ping tests

#10 2011-11-26 19:29:43

Re: Server ping tests

#11 2011-11-26 21:00:21

Re: Server ping tests

Board footer