Showing posts with label getting. Show all posts
Showing posts with label getting. Show all posts
Wednesday, March 11, 2015
A One Two Punch for Getting Even More out of Google Apps APIs
Editor’s Note: Guest author Steve Ziegler is a senior architect at BetterCloud—Arun Nagarajan
FlashPanel, a leading enterprise-grade security and management application for Google Apps, makes use of many Google Apps APIs. Each API comes with its own set of rate-limiting quotas, network traffic behavior and response conditions. The challenge we face is to provide our customers with a stable, consistent experience despite these API behavior differences. Fortunately, Google has provided two simple, yet powerful tools to greatly increase our success rate and reliability.
Google Apps APIs operate with quota rates per second or per day. As such, the FlashPanel development team’s objective is to minimize total operation time of a parallelized set of API-intensive processes while avoiding running into Google’s API quota limits. To accomplish this, we can very easily set up a thread-safe RateLimiter for a specific rate per second for each rate restricted API:
The Guava RateLimiter allows us to attempt to acquire a permit based on the configured rate per second, block until available, and then take it when available, allowing execution.
To use it within the context of a method, we simply reference the rate limiter before making the API call:
This provides us with a very easy solution for rate limiting parallelized calls to the same APIs.
Occasionally, we experience additional network traffic issues despite enforcing rate limits. Google suggests that API clients use an exponential backoff strategy to handle this variety of error response. Typically this category of network issue resolves itself on its own after fractions of a second, but occasionally more time is needed. All we need to do to receive a successful API response is to simply retry the call some number of times, with the interval of time between retries growing exponentially.
Again, Google has made this easy through the Google HTTP Client for Java library’s ExponentialBackOff builder. This class allows us to configure the initial retry time interval, the exponential multiplier, the maximum total time to attempt to retry, and the maximum total time between retries. For example, we could configure a retry to span five minutes, growing with a factor of two, starting at a one second interval, and growing up to a maximum of one minute between retries. An API call with this configuration would retry with the following pattern in terms of seconds between retries:
If after this last retry, the API call still was not successful, the failed http response is returned. The code to configure such a strategy using the ExponentialBackOff.Builder reads as follows:
One potential “gotcha” that we’ve seen is if we accidentally slam a particular API with many simultaneous API calls. In this event, not only would each of these API calls fail, but they would also schedule their retry strategy to occur simultaneously. All subsequent retries would end up firing simultaneously, causing the API calls to continue to fail due to excess per second volumes. The ExponentialBackoff class accounts for this by including a randomization factor within our retry logic that allows us to have each simultaneous API call stagger at different intervals.
For example, using our previous backoff but now with randomization, one API call may retry with these intervals:
While a second API call would retry with something like these intervals:
With this randomization, we avoid API call sequencing collision, mitigating our chances of encountering quota related errors. To simply add this type of randomization, we append to our builder:
Once we have our exponential backoff strategy configured, the Google HTTP Client for Java library allows us to instantiate and assign an HttpBackOffUnsuccessfulResponseHandler to an HttpRequest as part of the request’s initialization:
By restricting our API calls using Google Guava’s easy-to-use RateLimiter, and by employing an exponential backoff strategy using the Google HTTP Client for Java library’s ExponentialBackOff, we are able to significantly reduce the amount of network traffic errors received by our Google Apps API calls, improving FlashPanel’s reliability and the overall user experience.
Steve is Senior Architect at BetterCloud, the makers of FlashPanel, the number one security and management application for Google Apps. Follow BetterCloud on Google+ at plus.google.com/+Bettercloud.
Posted by Greg Knoke, Googler
Read more »
FlashPanel, a leading enterprise-grade security and management application for Google Apps, makes use of many Google Apps APIs. Each API comes with its own set of rate-limiting quotas, network traffic behavior and response conditions. The challenge we face is to provide our customers with a stable, consistent experience despite these API behavior differences. Fortunately, Google has provided two simple, yet powerful tools to greatly increase our success rate and reliability.
Controlling Throttle Rates with Guava’s RateLimiter
Google Apps APIs operate with quota rates per second or per day. As such, the FlashPanel development team’s objective is to minimize total operation time of a parallelized set of API-intensive processes while avoiding running into Google’s API quota limits. To accomplish this, we can very easily set up a thread-safe RateLimiter for a specific rate per second for each rate restricted API:
final RateLimiter driveApiRateLimiter = RateLimiter.create(QUOTA_RATE_PER_SECOND);
The Guava RateLimiter allows us to attempt to acquire a permit based on the configured rate per second, block until available, and then take it when available, allowing execution.
To use it within the context of a method, we simply reference the rate limiter before making the API call:
public Result performDriveApiCall(driveApiRateLimiter, otherParams){
driveApiRateLimiter.acquire(); // blocks according to rate
// make API call...}This provides us with a very easy solution for rate limiting parallelized calls to the same APIs.
Reducing Impact of Network Traffic Issues Through Configured Backoffs
Occasionally, we experience additional network traffic issues despite enforcing rate limits. Google suggests that API clients use an exponential backoff strategy to handle this variety of error response. Typically this category of network issue resolves itself on its own after fractions of a second, but occasionally more time is needed. All we need to do to receive a successful API response is to simply retry the call some number of times, with the interval of time between retries growing exponentially.
Again, Google has made this easy through the Google HTTP Client for Java library’s ExponentialBackOff builder. This class allows us to configure the initial retry time interval, the exponential multiplier, the maximum total time to attempt to retry, and the maximum total time between retries. For example, we could configure a retry to span five minutes, growing with a factor of two, starting at a one second interval, and growing up to a maximum of one minute between retries. An API call with this configuration would retry with the following pattern in terms of seconds between retries:
1, 2, 4, 8, 16, 32, 60, 60, 60
If after this last retry, the API call still was not successful, the failed http response is returned. The code to configure such a strategy using the ExponentialBackOff.Builder reads as follows:
ExponentialBackOff backoff = new ExponentialBackOff.Builder()
.setInitialIntervalMillis(ONE_SECOND)
.setMultiplier(2.0)
.setMaxIntervalMillis(ONE_MINUTE)
.setMaxElapsedTimeMillis(FIVE_MINUTES)
.build();
One potential “gotcha” that we’ve seen is if we accidentally slam a particular API with many simultaneous API calls. In this event, not only would each of these API calls fail, but they would also schedule their retry strategy to occur simultaneously. All subsequent retries would end up firing simultaneously, causing the API calls to continue to fail due to excess per second volumes. The ExponentialBackoff class accounts for this by including a randomization factor within our retry logic that allows us to have each simultaneous API call stagger at different intervals.
For example, using our previous backoff but now with randomization, one API call may retry with these intervals:
1.04, 1.9, 4.23, 7.8, etc.
While a second API call would retry with something like these intervals:
.98, 2.04, 4.1, 8.15, etc.
With this randomization, we avoid API call sequencing collision, mitigating our chances of encountering quota related errors. To simply add this type of randomization, we append to our builder:
builder.setRandomizationFactor(RANDOMIZATION_FACTOR);
Once we have our exponential backoff strategy configured, the Google HTTP Client for Java library allows us to instantiate and assign an HttpBackOffUnsuccessfulResponseHandler to an HttpRequest as part of the request’s initialization:
private HttpBackOffUnsuccessfulResponseHandler handler = new HttpBackOffUnsuccessfulResponseHandler(backoff);
public void initialize(HttpRequest request){
request.setUnsuccessfulResponseHandler(handler);
}
Final Thoughts
By restricting our API calls using Google Guava’s easy-to-use RateLimiter, and by employing an exponential backoff strategy using the Google HTTP Client for Java library’s ExponentialBackOff, we are able to significantly reduce the amount of network traffic errors received by our Google Apps API calls, improving FlashPanel’s reliability and the overall user experience.
Steve is Senior Architect at BetterCloud, the makers of FlashPanel, the number one security and management application for Google Apps. Follow BetterCloud on Google+ at plus.google.com/+Bettercloud.
Posted by Greg Knoke, Googler
Wednesday, March 4, 2015
OER Articles Reports Sites and Tools Getting Dizzy!
- Reference - OER Introduction Booklet
- Related Post - Giving Knowledge For Free & OER Stories
OER?"“Free sharing of software, scientific results and educational resources reinforces societal development and diminishes social inequality. From a more individual standpoint, open sharing is claimed to increase publicity, reputation and the pleasure of sharing with peers.” - Jan Hylen, OECD Centre for Educational Research and Innovation (Also check out Wikipedia - OER!)
Difference Between Educational Content Accessible for FREE and OER?
"A resource accessible for FREE over the Internet does not always signify that it is not protected by a copyright nor forbidden for reuse and reproduction. In fact, most of the time, the content is protected by copyrights not allowing reproduction. Where else an OER is distributed, licensed and shared with the background willingness to enable the user to adapt and use the content freely. There fore, the model of distribution and the license is always clearly mentioned (Source: OER Introduction Booklet)."
JUICE?
After exploring the OER Introduction Booklet further during the weekend, and a bit of reflection, I realize (dont ask me why!) I want to highlight a few valuable articles, reports, sites, and tools that we can explore further to get a better understanding about what OER is, why it is important, how we can use it, and how we can participate and contribute to make a difference. Most of the OER resources in this list are extracted from Thomas Bekkers excellent OER Introduction Booklet (Thanks!):
- By the International Institute for Educational Planning (IIEP): OER Glossary
This Wiki space maintained by the International Institute for Educational Planning (IIEP)
shares an open glossary of terms that have been used in the IIEP community discussions on Open Educational Resources (OER). - Giving Knowledge for Free: The Emergence of OER
The report offers a comprehensive overview of the rapidly changing phenomenon of Open Educational Resources and the challenges it poses for higher education. It examines reasons for individuals and institutions to share resources for free, and looks at copyright issues, sustainability and business models as well as policy implications. It will be of particular interest to those involved in e-learning or strategic decision making within higher education, to researchers and to students of new technologies ...more - Open Educational Resources (OER) Stories
"Case studies/stories of how institutions and individuals have developed or used OER would be a useful resource for awareness raising activities. Telling stories is a very powerful means of transmitting information. As one Community member (Zaid Ali Alsagoff) expressed it, "Stories inspire people and bring movements to life." - A Review of the Open Educational Resources (OER) Movement (PDF)
This report examines The William and Flora Hewlett Foundation’s past investments in Open Educational Resources, the emerging impact and explores future opportunities. - OER and Dissemination of Knowledge Indeveloping Countries
By David Steve Matthe. Why should anyone give away anything for free? Free sharing means broader and faster dissemination, and more people get involved in problem-solving, which means rapid improvement and faster technical and scientific development, and that free-sharing of software, scientific results and educational resources movements re-enforces societal development and diminishes social inequality, etc. - Why are Individuals and Institutions Using and Producing OER?
This excellent paper by Jan Hylen, introduces findings from a recent OECD study. Introductory remarks: "The first and most fundamental question anyone arguing for free and open sharing of software or content has to answer is – why? Why should anyone give away anything for free? What are the possible gains in doing that? Please read :) - Getting Started with Reusability? An introduction to Reusability for Digital Learning Resources
This article, published by the Reusable Learning project, provides an interesting overview
about the concept of "reusability" and knowledge transmission from the early age to todays modern societies to finally introduce reusability for digital learning resources and the systems that support them. - PRODUCE & REMIX OER: Author and Modify
This 60-minute tutorial provides information on and practical tasks in creating and modifying open content in an open process formats that can be published as open educational resources and tools, that support this process how to use standards and metadata. - OER and practices: a Slide Show with Audio introducing OERs
This slide show was published on Flickr.com and produced by Leigh Blackall. It includes audio, pictures and an article exploring OERs and practices in a tertiary educational institution. - By IIEP: OER Useful Resources
This list of links to OER initiatives, resources and tools was compiled following the first IIEPdiscussion forum on Open Educational Resources (24 October - 2 December 2005). It owes a considerable debt to Zaid Ali Alsagoff (That is my name! Cool!), who put together a first list of OER initiatives as an outcome of the forum. Practitioners will find some useful lists of Web sites related to OERs including portals, tools, OER development and publishing initiatives, communities, journals and more. - 80 OER Tools for Publishing and Development Initiatives
Arranged in alphabetical order, this list includes 80 online resources that you can use to learn how to build or participate in a collaborative educational effort that focuses on publication and development of those materials.
Also, if you are looking for a massive list of potential learning tools, you might want to check out UNESCO Free & Open Source Software Portal (Currently 604 tools!). Here are links directly to the major categories:
- Communication
- Courseware Tools
- Development Tools
- Operating System
- Productivity Tools
- Science and Education
- Digital Library
- Health
- Virtual Laboratory
Finally, if you are looking for a list of learning tools that combine commercial, open source, and free stuff, I believe Jane Knights directory of 1700+ learning tools (probably more now!) would be of great help (if you got time!).
Oh Man! I am getting dizzy! This post is heavy! As Stephen Downes says, "See, heres the thing, though. I dont want 99 (mind mapping) resources, tools, and tips. I want one. That works. Really well. (Source)." So, if you ask me to recommend only one learning tool to jump start an OER initiative, I would probably pick Moodle. Hey, dont jump the gun! Why think one! What about your mission, needs, requirements, analysis, bla, bla, bla... Before you know it, nothing really happens! Perhaps, we can learn a few lessons from New Zealands ongoing OER project. Goals, Strategy, Expertise, Pedagogy, Instructional Design, Content, Tools (Moodle, Fedora, etc.), Relevance... :)
Subscribe to:
Posts (Atom)