There was an interesting talk on running MapServer on Amazon Lambda - https://www.youtube.com/watch?v=g_WMDxsuCfk&t=2s The CGI approach of MapServer scales well as each request can be run separately (at a slight overhead for database connections, PROJ startup etc).
Seth -- web:http://geographika.co.uk twitter: @geographika On Fri, Apr 23, 2021, at 5:20 PM, Andreas Neumann wrote: > Hi, > > 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. > > Here is the link to the document (not in final form yet, but close to being > final): > https://docs.google.com/document/d/1cOUWgzalRx7CHWTFgHz6-uyScsCcoaEmYC0VBHdZShQ/edit#heading=h.c7gq4lie7ys2 > > 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? > > 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. > > 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. > > Do you know of any work in the UMN Mapserver community regarding cloud > deployment, cloud optimization, load balancing and resource sharing? > > 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. > > Thanks, > Andreas > > -- > Andreas Neumann > QGIS.ORG <http://qgis.org/> board member (treasurer) > _______________________________________________ > mapserver-users mailing list > [email protected] <mailto:mapserver-users%40lists.osgeo.org> > https://lists.osgeo.org/mailman/listinfo/mapserver-users >
_______________________________________________ mapserver-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapserver-users
