Per-Entity Metadata Working Group

[Patrick Radtke <>]

I realized I didn't reply to the list when I wrote this.
I setup Cloudfront as a caching CDN for the beta mdq server. Details
in the forwarded message below, along with my latency figures.


---------- Forwarded message ----------
From: Patrick Radtke 
<>
Date: Fri, Aug 26, 2016 at 3:57 PM
Subject: Re: [Per-Entity] Latency figures for CDNs
To: David Walker 
<>


On Fri, Aug 26, 2016 at 1:56 PM, David Walker 
<>
 wrote:
> Getting back to Nick's original question, I guess I am concerned about the
> latency times for 12KB objects (~0.4 secs in the US), unless we think
> InCommon sites have much better connectivity than Frost and Sullivan's
> average (and that the predominant latency factor is the last-mile network).
>
> This, of course, brings us back to Chris's admonition that we focus on
> business needs.  What delay is acceptable when an IdP or SP needs to
> retrieve the metadata for some other SP or IdP?  0.4 seconds sounds pretty
> long to me, but it is a rare event, we think.

I setup Cloudfront (US, Canada and Europe locations) to be a caching
proxy for the beta MDQ server.
A cache miss in the edge location closest to you will result in a
query going to the MDQ server. Cloud front will cache the result for
an hour.
You can test it by using http://drhqoesel6yr5.cloudfront.net/ in place
of http://mdq-beta.incommon.org/

Using curl to do the timing

curl -o /dev/null -s -w \
%{time_connect}:%{time_starttransfer}:%{time_total} \
http://drhqoesel6yr5.cloudfront.net/global/entities/https%3A%2F%2Ffm.incommon.org%2Fsp


I get, for a cache hit,
10-20 ms from an EC2 instance
33-50 ms from home
cache misses seemed to add 1 second.

If I hit the MDQ beta server directly I get
10-30 ms from EC2 instance (this surprised me)
175-200 ms from home.

I'd be curious to see what the variance is for people on this list.
Your first curl will be likely be a cache miss in the CDN.

-Patrick


-- 
Patrick Radtke
CTO
Cirrus Identity