search

EIDA / mediatorws

EIDA NG Mediator/Federator web services
GNU General Public License v3.0
6 stars 6 forks source link

fed, stl: Very slow response for simple query (networks in text format) #35

Closed javiquinte closed 5 years ago

javiquinte commented 6 years ago

The same query as in #28 . The timeout is not there anymore, because the Federator is streaming. Great. However, the performance is quite poor. It took almost 7 minutes to return the list of networks in the format. If I query the endpoints directly the answer comes in less than 1 second! (total time).

javier@sec24c79:~/git/fdsnws_scripts$ curl "http://federator-testing.ethz.ch/fdsnws/station/1/query?level=network&format=text" -o ~/delete.me % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 14879 0 14879 0 0 36 0 --:--:-- 0:06:42 --:--:-- 0

damb commented 6 years ago

Hi @javiquinte, thanks for your input. As long as the federator is not whitelisted by all EIDA nodes discussions regarding performance IMO should be postponed. Maybe we can use this issue here to track the whitelisting status from EIDA nodes.

cheers

Jollyfant commented 6 years ago

This is a symptom of #32 right?

Quote from #30:

Resolving requests to the channel level is not feasible for inventories. You cannot make over 40000 requests to the endpoints to collect information on all channels in EIDA. Even at 130 requests per second it will take you 5 minutes.

Math seems to check out :-)

damb commented 6 years ago

@Jollyfant, for level=channel you calculation is right. However, for level=station|network we already implemented a level reduction mechanism i.e. if you request fdsnws/station/1/query?level=network eida-federator exclusively sends one request/network code (for fdsnws/station/1/query?level=station one request/sta code). In those cases a granular approach should be feasible.

level=channel we discuss in #30 and #32.

cheers

kaestli commented 6 years ago

True that the throughput of our (eida.ethz.ch) fdsn/station implementation is at ~125-130 requests/second... The current implementation

Both design decisions lead to the fact that some further optimizations possible for fdsnws/station, if used with text format, are not applied. If this turns out to be a strong showstopper, we should consider to change this (and pay for it with different logging granularity depending on whether text or xml is requested, and potentially with different caches used). If the homogeneous processing is feasible (although not optimal for some specific cases), i would rather prefer sticking to it.

javiquinte commented 6 years ago

Please, @damb . I wrote to the EIDA mailing list but there was no answer yet. Could you tell us which are the nodes that are blacklisting the Federator? And apart from that, do you know why? Are they just not answering (timeout) or are nodes that take a lot of time? Details could be of great help.

damb commented 6 years ago

Are they just not answering (timeout) or are nodes that take a lot of time? Details could be of great help.

We talk about:

I'm going to provide a complete list which EIDA-Nodes are affected.

On 04:38 Fri 22 Jun , Javier Quinteros wrote:

Please, @damb . I wrote to the EIDA mailing list but there was no answer yet. Could you tell us which are the nodes that are blacklisting the Federator? And apart from that, do you know why? Are they just not answering (timeout) or are nodes that take a lot of time? Details could be of great help.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/EIDA/mediatorws/issues/35#issuecomment-399413636

-- | Daniel Armbruster | ETH Zürich - Schweizer Erdbebendienst (SED) | Email: daniel.armbruster@sed.ethz.ch | Phone: +41 44 633 24 80 | Sonneggstrasse 5 | 8092 Zürich | Switzerland

gpg --keyserver keys.gnupg.net --recv-key EF60F5CC

damb commented 5 years ago

Duplicate of #35.