Several weeks ago I mentioned a new ping service that I’ve been using for my blog, but I wasn’t able to give details since it was experimental. Well, the cat is now out of the bag!
PingQueue is Joseph’s recently-announced ping service. Details of this service are available via the links in this entry. But in a nutshell, the advantage of this service is that ping requests are queued up–this sounds like a disadvantage, but the response time for adding a request to the queue is much faster than synchronously pinging multiple services.
Check it out! I’ve been using this service for the last 1.5 months or so, and I’ve been very happy with it.
Kevin Burton frets about a potential “ping crisis”:
…in the long run it seems to be a big difficult (sic):
1. Everyone wants to spam you.
2. You’re not a consumer level service so you can’t run Ads to make money.
3. The more traffic you get the more your costs go up.
4. Scaling a system is difficult once you get to that volume.
5. All your pings need to be delivered fast (see #4).
Those are some interesting points to ponder. Point #1 is particularly troublesome, so let’s think about points 2-5 first. It seems to me that we’d do well to look at some other services for ideas and inspiration. The first one that comes to my mind is DNS. No ads on DNS, and not many fees are being charged for it. Perhaps we should come up with some sort of distributed model for handling blog pings? If we have a distributed service, no single server would have to bear the entire load, and we can probably avoid the traffic cost and scaling issues. But now about point #5 — Obviously pings need to be acknowledged very quickly, but do pings need to be delivered fast? Joseph’s ping service is based on a queueing model, which seems reasonable and more practical to me. What do I care if my posts are advertised “immediately” or I have to wait 5 minutes?
So now back to point #1, blocking spam. Do we need some sort of RBL? Open-source tools to identify spam? I really don’t know the answer to this. We need some input from people on the front lines about this topic.
Ping-o-Matic (the default pub-notification service in WordPress) is a great idea: You publish a new post, and WordPress notifies PoM, and PoM passes the update along to a whole bunch of update services. Very slick! But there are two problems with it:
- Single point of failure. If PoM is down (or busy or otherwise unavailable) when you click the Publish key, you’ll get to watch your browser spin in circles for a bit while it tries to contact PoM.
- Real-time pinging. If PoM is available when you Publish, it seems like it holds you connection while it notifies all the update services.
Joseph started discussing these problems with me the other day, and the delays I’ve sometimes noticed upon clicking the Publish button came to mind. Turns out that he had an idea for a streamlined notification service, which he’s now opened up for testing. I’ve installed the new service in place of PoM, and it seems to be a significant improvement. I’d like to collect some data comparing the new service to PoM, to get a more objective look at this.
Some things to note:
- Joseph’s service could still be a single point of failure, assuming one were to replace PoM with this service in the Options/Writing/Update Services setting.
- The basic idea of the new service is to respond to a blog’s update notification as fast as possible, then later to notify all the update services. The cost of this approach is a small delay (a few minutes) between publication and notification, but the quick response between clicking Publish and getting back to my blog admin page is worth it!
