aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sweeney <>
Subject Re: api vs apibeta
Date Mon, 29 Dec 2014 18:36:20 GMT
Interesting data, any chance you could share the source of these benchmarks
for others to reproduce? Can you confirm you used the getTaskStatus API
call with the same TaskQuery for both the JSON and the thrift client calls?

On Sun, Dec 28, 2014 at 10:27 PM, Isaac Councill <> wrote:

> tl;dr;
> apibeta seems way faster (and arguably better) than thrift api. What are
> the long term objectives for apibeta?
> Hi,
> I've been working on some aurora integrations, primarily a blackbox
> monitoring tool at present, and was looking for the best way to communicate
> with the scheduler.
> For a large read-only example, I wanted to dump the latest scheduler status
> info for all our prod jobs, basically:
> for all roles:
>   for all jobs in role:
>     get scheduler status
> We have about 120 prod jobs in aurora right now (growing fast). I
> benchmarked 3 strategies against our prod cluster (mean of 5 tries each
> from remote vpn, variance was small in each case):
> 1) aurora2 client: ./aurora2 job status cluster/<role>/prod > /dev/null
> 126.0sec
> 2) golang thrift API
> 584.3sec (I might be able make a better task query, but still... this is
> for only ~120 calls)
> 3) Pure json apibeta client in golang
> 13.4sec (again, might be able to optimize query strategy)
> As a side note, getting the golang thrift client to work was a very painful
> and illuminating experience.
> I'm inclined to stick with apibeta. It's fast and the documentation is
> great. If api changes become a concern, well after today I'd honestly
> prefer rolling my own binding generator.
> Are there plans for /apibeta wrt /api?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message