Performance Improvements at Genability

Genability takes API performance very seriously.  We’re committed to continuously improving the performance of our software products as we grow in both functionality and customer adoption. We spent a lot of time this summer enhancing the stability of our systems, culminating in our latest upgrade to Switch, which responds to API calls significantly faster and can handle much higher call volume.

Upgrading our Performance SLA

Genability is excited to announce an upgrade to our current Service Level Agreement (“SLA”) related to performance uptime. Effective immediately, our new standard uptime guarantee is 99.95%, up from 99.5%. You can always view Genability’s recent uptime performance at http://status.genability.com/.

Sometimes we may need to interrupt service for scheduled maintenance, which won’t count towards this 99.95% figure. We promise to only do such maintenance on the weekends and to announce it in advance. Note that in the life of the company, we’ve not yet had to implement a scheduled outage. If you are a current customer of Genability, your account representative will be reaching out to you shortly to upgrade your existing contract and answer any questions you may have.

Savings Analysis Call 8x Faster

Arguably our most important API is our Savings Analysis call, which compares future electricity costs under two scenarios, usually with and without solar. This allows solar developers to determine the avoided cost of power for a particular project or customer. It is one of our most demanding calls in terms of database access and CPU time, since it calculates three separate bills for 20 or more years into the future. Often, a solar salesperson is using a quote tool that calls our API while they’re in front of a customer, so response times are very important.

With this in mind we set out to reduce the average response time of Savings Analysis calls to under 500 milliseconds from around four seconds in June. As you can see from the graph below, we were quickly able to achieve our goal (an 8x improvement) in parallel with increasing call volumes from our new and existing customers. Current average response time is around 450 milliseconds.

Many different changes contributed to this increase in speed. We added caching to some of the most common database queries. We optimized the algorithms in the core calculation logic.  We upgraded our databases to newer and faster servers. And we optimized some of our other calls that were having a disproportionate impact on our servers. But most significantly, we refined our database queries and tuned database indexes.

Calls Faster Across the Board

Our optimizations, while mostly focused on the Savings Analysis call, have improved performance across all types of calls. Our Apdex, a measure of composite application performance, improved dramatically overall. Apdex is a number between 0 and 1, 1 being the best. We are alerted whenever the Apdex goes below 0.7. In June and early July this happened periodically. After our changes, Apdex has been consistently above 0.9, indicating that almost all API calls complete within a satisfactory timespan.

Handling Increasing Call Volume

As mentioned before and as visible on the graph, API call volume is increasing quickly. It’s currently doubling every four to six months. In our load-testing environment we have confirmed that we can maintain responsiveness when handling eight times the current load. We load-test each release before we deploy to production to make sure we maintain this headroom.

What’s Next?

We continue to work towards lower response times and higher uptimes. We are adding more caching and spending more effort optimizing the most critical pieces of code. For example, we have an initiative to re-architect the way we store fine-grained (time-series) meter data, as we are seeing exponentially more of this. As always, we continue to monitor day-to-day API performance to make sure we’re keeping up with increasing call volume.