Observations on API and Mashup Management API and Mashup Blog
Is Apigee ready for your Production App?
One frequent question over the last six weeks is "if Apigee is still a preview product can I use it for my production app?"
Yes, you can use Apigee as a proxy for production APIs. Dozens of production apps run on Apigee today. (many of which we'll keep showcasing on this blog)
The current Apigee preview is built on a proven platform and architecture that delivers carrier-grade levels of uptime. Some specifics:
- Apigee's core is our Sonoa ServiceNet enterprise platform. This is the same API Infrastructure that runs over 60 financial services, media, and SaaS companies running critical apps at high traffic levels.
- From the load balancers to the database and everything in between, we built redundancy into every level of Apigee.
- We designed Apigee for zero downtime upgrades so that your proxies will stay up and running even as we apply fixes for bugs and enhance Apigee with new features.
- Our uptime targets for the preview are 99.9% for API proxies and 99% for the Apigee website.
- And we have operational teams in San Francisco, USA and Bangalore, India constantly monitoring Apigee so that we can respond 24x7 to any issues.
So even though Apigee is currently in private preview, we take your business very seriously and we've built the service to be enterprise-grade from the ground up.
How Apigee calculates API error rates (featuring Twitter Growl and the Detroit Tigers)
Last time we showed how Apigee calculates API response time. This time we want to discuss how Apigee calculates API error rates.
Apigee provides charts and tables with API error rates by day, hour or minute with drill downs by API URL.
The 'error rate' calculation itself is simply # of errors divided by # of requests. Errors include both any Apigee error (including those that you might configure) or any target error (such as a rate limit error from the Twitter API).
Let's show this with Brian's Twitter Growl mashup. Twitter Growl provides alerts on topics using Mac's Growl alerts. For example, Brian gets alerts for Tweets on Detroit and Michigan news.
Brian monitors Twitter Growl API activity using Apigee. You can see he had some stretches in mid August and early September with high error rates.
You can also drill into the days or hours where these spikes in errors occurred, such as this 3 day period in September - high error rates on a single IP that was being rate limited by the Twitter API.
What was happening over this time? The Detroit Tigers - in a pennant race for the AL Central - were swept in a 3 game series with the Royals, resulting in rate-limit busting volumes of angst-ridden tweets from the Detroit Twitterati.
So there you have it. The Tigers are behind all the errors. (not sure we needed Apigee to tell us that.) And they still have a 4 and 1/2 game lead, FWIW.
If you'd like Twitter Growl to keep you up to date about the Tigers or any other topics on Twitter, thanks to Brian - his version is a fork of a project by visnup on github
How Apigee calculates API response time
Earlier this week we showed how to caculate the latency that Apigee adds to your total API transaction (vs. not using Apigee as a proxy).
This is different than the API 'response time' that you see in your Apigee API analytics dashboard graphs and tables.
If you've set up your Apigee proxy and have run some traffic, you'll see graphs for "response time" in your Apigee dashboard. (If you haven't seen a dashboard yet, these metrics include messages, developers, error rates, data in/out, and response time)
For example, the widget above and charts below are some of the data I see for the before/after latency test I ran against the Yahoo Local API in the previous API latency blog entry, 
This 'response time' is the roundtrip latency from time time your request enters Apigee - hits the target - waits for the target's response and that response leaves Apigee on the way back to your client.
Here is how your Apigee dashboard cacluates "response time". For the timestamps:
• T1 – when message arrives at Apigee
• T2 – when message leaves Apigee to go to the target (in this case the Yahoo Local API)
• T3 – when message arrives at Apigee from the taget
• T4 - when messages leaves Apigee to the Client
The Apigee 'response time' graph/table shows T4 - T1 = Response times of the Apigee Proxy including time taken by the Target. In this case, the Yahoo Local API response time was about 23 ms.
Hope this is useful and we'd love your comments or questins here or on our support and feedback forum.