EMIKAT Map server is extremely slow

Question

EMIKAT Map server is extremely slow

Closed this issue 5 years ago · 8 comments

I have just tested the https://csis.myclimateservice.eu/study/35/step/1528/view/maps and getting the map to show takes like forever. It does show up in the end...

This also means that taking a screenshot takes forever and a day. I thought it's broken at first, but it turned out that it's just slow. Ah wait, it's worse than that - the overlay is not included in the screenshot at all.

:-(

Can we have a faster map server on EMIKAT side?

Answer 1 · 2019-10-01T10:56:53.000Z

the overlay is not included in the screenshot at all.

@therter Can you please check that?

Answer 2 · 2019-10-01T11:35:27.000Z

I suspect that it's simply a timeout error.

…

On Tue, 1 Oct 2019, 12:56 Pascal Dihé, ***@***.***> wrote: the overlay is not included in the screenshot at all. @therter <https://github.com/therter> Can you please check that? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AAWTC7QI4BB3LO6YIK6HQSTQMMUHTA5CNFSM4I4HML72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAA3N2A#issuecomment-536983272>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWTC7QCSHJMCKE3TVT5AQ3QMMUHTANCNFSM4I4HML7Q> .

Answer 3 · 2019-10-01T14:20:19.000Z

the overlay is not included in the screenshot at all.

@therter Can you please check that?

@DenoBeno is right. There is a default timeout of 15 seconds. Although the behavior of html2canvas is quite strange. It waits for the WMS response and then the image will not be used, if the response took more than 15 seconds.

I can increase the timeout or disable it.

Answer 4 · 2019-10-01T16:49:42.000Z

What we really need is that @humerh speeds up the WMS. Disabling the timeout... Don't know, @p-a-s-c-a-l WDYT. Would this break anything?

Answer 5 · 2019-10-02T06:34:01.000Z

I am already looking for a solution.
It seems, that you (or Map Component) uses for each layer a new WMS Connection.
The current implementation of the Emikat-Plugin to Geoserver does not support "Connection pooling".
I am now testing the changed implementation and if everthing goes well I will install today an optimised version.

Answer 6 · 2019-10-02T09:54:46.000Z

@humerh : that might be part of the problem, but I'm currently waiting for https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2975&bbox=4672000.0,1979500.0,4687500.0,1988000.0&width=768&height=421&srs=EPSG:3035&format=image/gif&CQL_FILTER=STUDY_VARIANT=%27BASELINE%27%20and%20TIME_PERIOD=%27Baseline%27%20AND%20EMISSIONS_SCENARIO=%27Baseline%27%20AND%20EVENT_FREQUENCY=%27Rare%27%20AND%20SZ_ID=2846 to load.

It's been 3 minutes and I'm still waiting to see anything. Now it broke with an error, maybe you are updating it right now?

Please try to measure the time once you are done. Something like this should do:

time wget -O wget.png "https://clarity.meteogrid.com/geoserver/europe/wms?service=WMS&version=1.1.0&request=GetMap&layers=europe:HI_summer-days_rcp26_20110101-20401231_ensstd&bbox=2145642.726143716%2C982955.8095900388%2C6605432.868301096%2C5706496.981659953&width=725&height=768&srs=EPSG%3A3035&format=image/png"
--2019-10-02 11:49:30--  https://clarity.meteogrid.com/geoserver/europe/wms?service=WMS&version=1.1.0&request=GetMap&layers=europe:HI_summer-days_rcp26_20110101-20401231_ensstd&bbox=2145642.726143716%2C982955.8095900388%2C6605432.868301096%2C5706496.981659953&width=725&height=768&srs=EPSG%3A3035&format=image/png
Resolving clarity.meteogrid.com (clarity.meteogrid.com)... 88.99.139.162
Connecting to clarity.meteogrid.com (clarity.meteogrid.com)|88.99.139.162|:443... connected.
HTTP request sent, awaiting response... 200 
Length: unspecified [image/png]
Saving to: ‘wget.png’

wget.png                                                        [ <=>                                                                                                                                      ]  62,03K  --.-KB/s    in 0,01s   

2019-10-02 11:49:30 (4,35 MB/s) - ‘wget.png’ saved [63520]


real	0m0,175s
user	0m0,011s
sys	0m0,007s

Answer 7 · 2019-10-02T16:18:40.000Z

The main reason of bad performance was, that the filter conditions where applied AFTER the fetch of all cells of ALL studies.
Now I forward the filter conditions to the database and the performance seems to be much better.

Additionally I implemented a database pool, but that was not the Performance killer.

Please give feedback to the current performance and behavior.

Answer 8 · 2019-10-03T08:25:17.000Z

Excellent!

https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2975&bbox=4672000.0,1979500.0,4687500.0,1988000.0&width=768&height=421&srs=EPSG:3035&format=image/gif&CQL_FILTER=STUDY_VARIANT=%27BASELINE%27%20and%20TIME_PERIOD=%27Baseline%27%20AND%20EMISSIONS_SCENARIO=%27Baseline%27%20AND%20EVENT_FREQUENCY=%27Rare%27%20AND%20SZ_ID=2846 loads instantaneously now.

Showing "local effect temperature" on https://csis.myclimateservice.eu/study/35/step/1524/view/maps takes maybe 1-2 seconds.

Same for population distribution on https://csis.myclimateservice.eu/study/35/step/1529/view/maps, and for the https://csis.myclimateservice.eu/study/35/step/1528/view/maps, except that it feels a bit longer because they first need to build an map and zoom in & the map is then immediately shown.

This is definitely acceptable speed now. Taking report images works OK too.

Closing the issue.