Tag Archives: RTT

Faster API Response Times By Limiting Reviews and Offers

I’m exploring the different ways to speed up API response times with the CityGrid APIs. The APIs are fast, and I’ve built several local directories and business search tools that use the API in real-time, with great results. But speed is something that CityGrid engineers and publishers are concerned with, so I will continually explore ways that I can speed of API round trip times (RTT).

Couple days ago I talked about better round trip times with GZip, and today I’d like to talk about enhancing response times by limiting reviews and offers. Generally reviews or offers takes about 20ms each to run (but can occasionally take 50 or 100ms). Since we request reviews, offers, and content (like editorials, website link, menu link, images, etc.) in parallel, the caller only pays for the max of the 3 times with each CityGrid Places API calls. So if the times are like this:

  • Content=12ms
  • Reviews=20ms
  • Offers=22ms

The total time used is 22ms. The place where this can be a real problem, is if reviews or offers times out. Currently the timeout on these services is 400ms (to be reduced to 100ms in the future). So if you are really wanting to improve the RTT and minimize latency you can disable reviews/offers using the following two parameters: review_count=0 and offer_count-=0. This will take the llatency and time-out of those services out of the equation.

So if you are just wanting the core places content and will not need the reviews or offers, you can significantly reduce the payload by disabling these upon request from the CityGrid Places API.

Better Round Trip-times (RTT) With CityGrid API Using GZip

One of the biggest questions I get when talking with CityGrid developers are around storing our data. Everyone wants to store the 15 million businesses CityGrid has in their own database. My response is really? You do?

This type of thinking comes from legacy thoughts around database driven applications and concerns about network latency. I counter these with a couple of points:

  1. You don’t want to be in big data business, we have teams of engineers working to ingest, clean, optimize and serve up this data. Do you really want to assume these responsibility.
  2. Our places, images, reviews, offers and other content is updated in real-time. If you store the data, you’re missing out on a lot of content that may change frequently.
  3. Speed is getting to be less of a concern when making calls to our APIs–you are looking at millisecond responses and in some worst case scenarios, 1 or 2 seconds.

Usually I can convince most developers about points 1 and 2. But speed is still an ongoing battle. We are working all the time at CityGrid to improve our API response times. But there are things you the developer can do to improve response times also.

One tactic that isn’t available in our documentation, is the use of GZip. With each API request you can set a HTTP header as Accept-Encoding: gzip, and the CityGrid will compress the responses for you, significantly reducing your round-trip time (RTT). Once you receive the response from CityGrid API you can uncompress using the GZIP decoding functionality available in any programming language.

Reducing the size of the data being transmitted is a great way to increase your RTT, which makes relying on any API for real-time calls, much more realistic. I recommend giving it a try when integrating your web or mobile app with the CityGrid Places, Reviews and Offers APIs.