HTTP Client Attributes

Cantor, Scott cantor.2 at osu.edu
Mon May 7 17:13:13 EDT 2018


> Okay, you can change it, or you can explain it to me and I'll be happy to
> change it. Whatever works best.

Caching small documents is valuable only to the server, it's got little impact on a client. If you want to come at it from that direction, ok, but it has nothing much to do with the performance of the IdP other than by lightening the load on the source.

> As a specific example, suppose you have a resource that is normally updated
> daily on the server side. Let the cache duration be 4 hrs. Now the client
> initially fetches the resource and commits it to the cache.
> The next 4 hrs are free (no HTTP requests). At the end of 4 hrs, the cached
> resource becomes invalid. The very next time it's needed by the IdP, the
> client sends a conditional GET request to the server. If we're still within the
> 24 hr period, the response will be 304 and so the client marks the cached
> resource as valid, at which point the next
> 4 hrs are free. The rest of the life cycle should be clear.

Every single time it gets that 304, the Apache HttpClient returns the cached response body to the IdP internally, at which point it parses that XML and verifies the signature and does absolutely everything it did the first time. There is zero optimization other than skipping transmission of a small amount of data across the network.

> I don't know what that means.

The batch plugins do their own HTTP caching and issue their own conditional GET, allowing them to detect the 304 result and skip all the processing they would have done. This saves both the gigantic network overhead and the massive parsing and signature cost.

The dynamic plugins do NOT do this. They ask the HTTP client for a response, and the client internally says "here it is" or "error". There is no 304 notion. That's internal to the client and is never seen by the plugin so it has no chance to bypass any of its work. Every single "fetch" results in a totally new load of metadata regardless of whether it actually changed. This is only tolerable because the number of fetches is limited by the internal metadata cacheDuration and the plugin settings.

> I guess you're referring to the cache duration timeouts, in which case I totally
> agree.

No, I am not referring to anything to do with caching. I mean timeouts, period. Socket, connection, response. Network timeouts.

-- Scott



More information about the dev mailing list