Debugging slow REST requests

If you are seeing slow REST requests, there are a few different possible reasons why.

1. Routing. We use latency-based routing, but it occasionally happens that some requests end up routed to the wrong datacenter.

To investigate this, from the machine on which you're experiencing slow REST requests, run

curl http://rest.ably.io/404

which will give a 404 error which will include the server ID, which will include the AWS region (which you can map to a location with this table). Is the region you're being routed to a reasonably close one given your machine's location?

2. SSL handshake. Our client libraries use https for all endpoints by default, unless it's explicitly disabled. Establishing a TLS connection involves a three-way handshake. This is not normally a problem, but if your latency to our nearest datacenter is quite high anyway, it can compound the issue.

To investigate this, from the machine on which you're experiencing slow REST requests, run

curl -o /dev/null -s -w "time_namelookup:  %{time_namelookup}\n time_connect: %{time_connect}\n time_appconnect: %{time_appconnect}\n time_pretransfer: %{time_pretransfer}\n time_redirect: %{time_redirect}\n time_starttransfer: %{time_starttransfer}\n time_total: %{time_total}\n" https://rest.ably.io/time

and then repeat with http://rest.ably.io/time (without the 's', so the non-ssl endpoint).

The `time_appconnect` result will tell you how long it takes for the SSL handshake to complete, before the request is actually sent. (Note that when using an actual client library, unlike with curl, rest requests use HTTP keep-alive, so the TCP connection doesn't need to be renewed for every request if you are sending multiple in close proximity).

3. Channel creation. If you are publishing to a channel which was not previously active in the region you're publishing to (or especially if it was not previously active at all) , the channel must be created first. This involves a handshake with other regions in the cluster, which adds latency.

See How does Ably count peak channels? for more information on when channels are active.

For example, if you are publishing once per minute and there are no subscribers, you may be racing with the channel getting deactivated and garbage collected (either globally or in that region).

The quickAck option may help with this as in the case of an inactive channel it will not wait for the channel to be created. See https://knowledge.ably.com/why-are-some-rest-publishes-on-a-channel-slow-and-then-typically-faster-on-subsequent-publishes for more information on this option.

4. REST request overhead. REST publishes inherently have somewhat higher latency than realtime publishes, as they have to authenticate, check capabilities (which may involve a database lookup), and so on anew for every request. So if very low latencies are important to you, we generally recommend using a realtime client library. This will avoid several of the above issues, because realtime libraries maintain a persistent websocket connection to Ably and multiplex all operations through that, which means SSL-handshaking, capability checking, channel attaching, etc. is done only once, rather than per-message.

See Should I use the REST or Realtime library? for more information on choosing between REST and Realtime libraries, especially the "Publish patterns" section towards the end.

Also see Why are some REST publishes on a channel slow, and then typically faster on subsequent publishes?

Further reading