fed: Optimization - hard coding some "common" queries.

[Jollyfant]

We should consider having some special treatment for some very common queries. E.g. asking for all stations in EIDA:

http://127.0.0.1:8080/fdsnws/station/1/query?format=text&level=channel

could possibility only hit all the endpoints only a single time and simply concatenate the results. I think for some derived products this will be an important query to optimize.

[damb]

It is a workaround. It might help temporarily. However, it does not solve the problem we have at endpoints i.e. fast data access. Especially when requesting data concurrently. Your approach only might work cause endpoints have results already cached for some very common requests.

[Jollyfant]

Yeah it's an workaround / specific optimisation, doesn't have a high priority.

[kaestli]

A reasonable, adaptive optimization would be to have a reverse proxy with mod_cache (cache persistence time e.g. 30 minutes) and herding prevention in front of federator/station. This would guarantee that:

• any often requested (or temporarily often requested) station request is served from cache with a high probability
• no identical request is processed twice in parallel.

This could be done on both sides of the federator, i.e. for requests from the user to the federator as well as for requests from the federator to the end node. The latter would probably solve the issue of slow response when asking for large amounts of inventory (without improving end node performance), as any inventory request would contribute to maintain fresh partial caches of inventory, ready to be used by requests for e.g. the entire eida inventory. We can explore to add that to the standard web server config proposal.

[damb]

Closed with #85. Reopen if required.