<div dir="ltr"><div>While we are moving a bit away from specific mapserver questions :) ... </div><div>Maybe we can do a MS Teams call (or something) if you have additional questions. It is probably also more practical in communicating over these topics. </div><div><br></div><div>But to answer your questions:</div><div><br></div>"Do you have more to share regarding this proxy service?"<br>Sure I can share a bit about our progress so far. At this moment there are 2 projects:<div>- ogc-webservice-proxy</div><div>- ogc-specifications</div><div>The ogc-webservice-proxy is still a private repo (because it is far from finished) but the <a href="https://github.com/PDOK/ogc-specifications">https://github.com/PDOK/ogc-specifications</a> is publicly available. Both are written in golang, the ogc-webservice-proxy is a http proxy application and the ogc-specifications is a package containing the "latest" OGC specifications so one is able to (un)marshall OGC XML/KVP requests to code. This is also still a work in progress especially how to implement everything and keeping it "readable"/usable.<div><br>"What is the purpose of it and how does it work? /you mention for determining the size/duration/location"<br>The useage of our NGDI has matured, people used to be happy they got 'something' now they start looking more at the metadata, quality, performance, capabilities...<br>This led to discrepancies between what and how the NGDI was initially deployed (the underlying software) and advertised (or rather what was not advertised) and what it has become through the vast amount of fixes/patches and so on.<br>One of the first challenges we identified are the differences between vendor capabilities <> ogc capabilities <> inspire capabilities.<br>What was/is missing in that equation are our own NGDI (PDOK) capabilities. Because for example maybe we want to disable POST requests, not allowing certain FILTERS with more than X filter options, or BBOX with a footprint larger then X. Basically we want/need to intercept the request</div><div><br>"Do you also separate short-running requests (e.g. GetFeatureInfo or GetLegendGraphics) vs long-running requests (GetMap, printing services, report generation)?"<br>Yes and No, for a lot of GetCapabilities requests we are routing them to 'static' XML-files instead of letting the backend generate them every time, and printing services have their own services (with higher timeouts). But this has been an artifact of the 'fixing' specific dataset/service issues, instead of a concrete plan in fixing the handling of all of our requests. And that is what we are trying to do with the ogc-webservices-proxy.</div><div><br>"Is your "traefik" load balancer using "round robin" load balancing or something more advanced based on system load or even by using an estimate/prediction how long a request might take based on the parameters submitted?"<br>Yes it is using a 'simple' rrb, and how we are looking at it, that it is going to be like that. Getting specific OGC logic into traefik/NGINX/apache/lua-scripting is something we are not going to do any more. This specific logic will be moved toward the ogc-webservice-proxy. Regarding system load, if it are valid requests we will depend upon the k8s node and pod autoscaling. But we are also now in a modus that: not every request has to be successful, as long that the handling is done properly. <br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 27, 2021 at 5:39 PM Andreas Neumann <<a href="mailto:andreas@qgis.org">andreas@qgis.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>Thanks for your reactions and replies to my request if there is experience in running UMN MapServer in the cloud. Sorry about the delay in responding.<br></div><div><br></div><div>I had a look at the MapServerless AWS Lambda Layer project and corresponding video. Thanks for sharing this work!<br></div><div><br></div><div>Pre-rendered tiles are of course good for background maps, but for other layers, esp. frequently updated layers and layers where we want to allow custom styling, feature info, etc. map tiles are not good alternatives.</div><div><br></div><div>Interesting to me was the feedback from Wouter about the Dutch NGDI (PDOK), which seems to be more similar to our GDIs (province level and national level OGC services in Switzerland). Interesting to hear that you are copying data as close as possible to the pods (Geopackage or by bringing Postgis really close to the Pods).</div><div><br></div><div>In the case of QGIS Server it is also interesting to see that the different vector data seem to matter substantially. We have a QGIS Server performance suite published at <a href="http://test.qgis.org/perf_test/graffiti/" target="_blank">http://test.qgis.org/perf_test/graffiti/</a> --> scroll to the latest date. In the performance test suite there is a section comparing different vector data sources. See f.e. <a href="http://test.qgis.org/perf_test/graffiti/2021_04_27_01_00/report.html#c395b4ae16b447f1b3e6fc127a4531da" target="_blank">http://test.qgis.org/perf_test/graffiti/2021_04_27_01_00/report.html#c395b4ae16b447f1b3e6fc127a4531da</a> where Postgis and SpatiaLite data sources are substantially faster than Shapefile and Geopackage is clearly the looser. Not sure if the same applies for UMN MapServer? Maybe that is a pattern that applies to QGIS Server only ...<br></div><div><br></div><div>Wouter: I would be interested in learning more about the "ogc-webservice-proxy" you mention for determining the size/duration/location. Do you have more to share regarding this proxy service? What is the purpose of it and how does it work? Do you also separate short-running requests (e.g. GetFeatureInfo or GetLegendGraphics) vs long-running requests (GetMap, printing services, report generation)?</div><div><br></div><div>Is your "traefik" load balancer using "round robin" load balancing or something more advanced based on system load or even by using an estimate/prediction how long a request might take based on the parameters submitted?</div><div><br></div><div>Thanks all for the interesting discussion!<br></div><div><br></div><div>Andreas<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 23 Apr 2021 at 22:07, Wouter Visscher <<a href="mailto:wouter.visscher@gmail.com" target="_blank">wouter.visscher@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Andreas,<div><br></div><div>To answer your question: "Do you know of any work ...."</div><div><br></div><div>For the Dutch National Geodata Infrastructure (PDOK) we are running now (over a year) hundreds of OGC WMS/WMTS/WFS servers (primarily Mapserver and Mapproxy) on aks (Azure kubernetes).</div><div><br></div><div>The challenges you are describing sound very similar to ours :)</div><div><br></div><div>To give some small inside on some of our solutions regarding:</div><div>deployment: kustomize and operators</div><div>cloud optimization: (regarding data) geohashes over GPKG and PostGIS tables and getting the data as close to the pods as possible.</div><div>load balancing: (infrastructure wise) 'standaard' loadbalancing with traefik, (OGC wise) we are working on a 'ogc-webservice-proxy' for determining the size/duration/location, basically what is going to be the impact of a request.</div><div>resource sharing: (infrastructure) ScaleSets for nodes, and ReplicaSets based on load, (data) because we have most of the data in GPKG we 'copy' the data around. So for a service that scales up to 4 pods we have 4 of the same GPKG copied to that node.</div><div><br></div><div>I will share your knowledge with my colleagues, but it seems you reached a lot of the same conclusions (so far I have read) we have. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 23, 2021 at 5:20 PM Andreas Neumann <<a href="mailto:andreas@qgis.org" target="_blank">andreas@qgis.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>For a small project as part of the Swiss National Geodata Infrastructure (grant project) several people worked on a study document called "Cloud-optimized OGC WMS Server" where we analyzed problems that can arise when you install an OGC web server in the cloud (e.g. docker image deployed via Kubernetes, OpenShift or the likes). This work had a focus on QGIS Server with it's own set of problems - but some of the issues studied in this document also matter for other OGC WMS servers, such as UMN Mapserver or Geoserver, such as the load balancing problem, how to share resources, etc.</div><div><br></div><div>Here is the link to the document (not in final form yet, but close to being final): <a href="https://docs.google.com/document/d/1cOUWgzalRx7CHWTFgHz6-uyScsCcoaEmYC0VBHdZShQ/edit#heading=h.c7gq4lie7ys2" target="_blank">https://docs.google.com/document/d/1cOUWgzalRx7CHWTFgHz6-uyScsCcoaEmYC0VBHdZShQ/edit#heading=h.c7gq4lie7ys2</a></div><div><br></div><div>I wonder if any similar work has been done specifically around problems, challenges and solutions when you deploy UMN Mapserver in cloud environments? Do you know of any work?</div><div><br></div><div>One major problem that probably all installations of an OGC WMS server have is how to deploy a more intelligent load balancing system? Often, the default load balancer is some kind of round robin load balancer system, but often this leads to inferior results where "cheap and short" requests (such as a simple GetFeatureInfo or GetLegendGraphics request) can be queued behind a long-running GetMap request (potentially with many layers, many features and a high-dpi, such as 600dpi, where the request can take several seconds to process.</div><div><br></div><div>In our production system we are currently separating the requests to dedicated instances for short requests and potentially long requests, to avoid the above mentioned scenario, but we are not so satisfied with the solution, as it is  a bit inflexible and also a bit harder to maintain. Ideally, we would like to have a more intelligent load balancer with incoming queue that holds back requests as long as all WMS server instances are busy. This would avoid the situation where a "less intelligent" load balancer would simply forward the requests to instances based on Round-Robin principle.</div><div><br></div><div>Do you know of any work in the UMN Mapserver community regarding cloud deployment, cloud optimization, load balancing and resource sharing?</div><div><br></div><div>In our study document I'd like to also include the perspective of other WMS servers besides QGIS server, so any input would be welcome.</div><div><br></div><div>Thanks,</div><div>Andreas<br></div><div><br></div><div>--<br><div dir="ltr"><div dir="ltr"><div>Andreas Neumann<br></div><a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> board member (treasurer)<br></div></div></div></div>
_______________________________________________<br>
mapserver-users mailing list<br>
<a href="mailto:mapserver-users@lists.osgeo.org" target="_blank">mapserver-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br>
</blockquote></div></div>
_______________________________________________<br>
mapserver-users mailing list<br>
<a href="mailto:mapserver-users@lists.osgeo.org" target="_blank">mapserver-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><br>--<br>Andreas Neumann<br></div><a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> board member (treasurer)<br></div></div>
</blockquote></div>