地理服务器和线程数
我们正在使用 Geoserver，并且在大量用户的生产中存在性能问题。
我们使用 250、150 和 20 个线程进行了一些负载测试。我们注意到，Geoserver 在 20 个线程下的工作效果比在 150 个线程下的工作效果更好，并且当线程数量增加（150 或 250）时，性能会下降。
正常吗？ Geoserver如何管理用户请求？ Geoserver是否使用异步策略来管理用户请求？
提前致谢。
博世
We're using a Geoserver, and we've a performance problems in production with a large number of users.
We've made some load test with : 250, 150, and 20 threads. We've noticed that Geoserver works better with 20 threads than with 150 threads, and when thread number increase (150 or 250), performance decrease.
Is it normal ? How Geoserver manage the users request ? Does Geoserver use asynchronous strategy to manage users request ?
Thanks in advance.
bsh
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
听起来很正常。线程（和 cpu 上下文切换）不是免费的，在某些时候，您将花费更多的时间来切换线程，而不是实际做任何有用的事情。通常最好将线程数量少得多（核心数量 * 2 通常是合理的），并结合某种前端队列，该队列将接受连接并保留它直到工作线程空闲。
Sounds pretty normal. Threads (and cpu context switches) aren't free, and at some point you are going to spend more time thrashing around switch threads than actually doing anything useful. Often better to have a much smaller number of threads (number of cores * 2 is often reasonable) combined with some sort of front end queue that will accept a connection and hold it until a worker is free.
线程越多，服务器上的负载就越重。请参阅有关 thrasing 的维基百科文章。
Geoserver 性能受多种因素影响。我的建议是逐一查看，看看瓶颈出现在哪里。
以下是帮助您走上正确道路的问题列表：
您的机器的规格是什么？它应该有一个 SSD。
您正在生成瓷砖吗？或者他们是预先播种的？
注意：预播种有帮助，但会损害系统，因此最好在生产中完成。
你的数据来源是什么，如果是postgis，你是否使用空间索引？
您正在生成多少种类型的图块？
注意：您可能会生成不需要/使用的额外图块。
您是否使用GeoWebCache？
如果有更多细节，我可以帮助你。
The more threads, the harder the load on the server. See WikiPedia article on thrasing.
Geoserver performance is affect by many things. My advice is to look at each one and see where the bottle neck be occurring.
Here are a list of question to set you on the correct path:
What are the specs of your machine? It should have an SSD.
Are you generating your tiles on the way? Or are they pre-seeded?
NOTE: pre-seeding helps but hammers the system so best done out of production.
What is the source for your data, if postgis, are you using spatial indexes?
How many types of tiles are you generating?
NOTE: you could be generating extra tiles which you don't need/use.
Do you use GeoWebCache?
With some more details, I can help you out.
以下是一些现实世界的用例统计数据；在生产中，对于为户外市场的“google-maps”风格用户提供服务的移动/网络应用程序，我的公司测试了各种配置（theonlysandman，这个问题的贡献者），也支持 Tyler Evans，也是这个问题的贡献者）。
我们需要每秒超过 5000 个请求 ('qps) 的负载，并且由于我们的 Geoserver 实例普遍达到每个近 100 qps 的峰值，因此我们需要水平和垂直扩展至超过 50 个 Geoserver 实例。
参数：多为矢量源，本地PostGIS数据库均小于2tb且无表> 1M 记录（或者如果大于 1M，则在节点间隔 > 1m 处简化几何结构），60%-40%-10% WMS/WMTS/WFS 请求，谷歌云托管服务器，每个 32 个核心，SSD 驱动器集群至 4Tb。
qps 的瓶颈似乎是 Geoserver 本身。 （样式、重投影以及随之而来的所有细节）。我并不是说它写得不好，但汽车越重，它的行驶速度就越慢。
如果我们使用 GO 或 python +/- gdal 复制 wfs 请求来直接访问 postgis 数据，我们将获得比 geoserver 更快的吞吐量（每个实例高达 1000 qps 或更多，其中 PostGIS 成为瓶颈）。
我们基于 PostGIS 的自制 Java 微服务也是如此，它从 postgis 创建 pbf/mvt 切片 - 它也非常快 - 大约 1000 qps。
对于我们来说，Nginx 的性能比 php 稍好（~110 qps vs~89 qps），但这可能是 apache 配置的结果。
我们该去哪里？在我们所有的生产用例中，对于我们的用户来说，提供微型分片 sqlite/mbtile 数据库（矢量或栅格）...并使用自定义代码维护它们...性能和可扩展性要高得多。
我们可以为 geoserver 编写一个 Java 插件，将 GeoWebCache TMS 图块推送到专为灵活的 z/x/y 调用而设计的 Google 存储桶中……这样我们就可以使用 Geoserver 工具更轻松地维护包含更新等的图块金字塔。
Here are some real-world use case statistics for you; in production, for mobile/web apps serving 'google-maps' style users for the outdoor market, my company has tested various configurations (several of these discussed by theonlysandman, a contributor to this question), and which also support the observation by Tyler Evans, also a contributor to this question).
We need loads of greater than 5000 requests / second ('qps), and as our Geoserver instances ubiquitously topped at nearly 100 qps each, we'd need to horizontally and vertically scale to over 50 Geoserver instances.
Parameters: mostly vector sources, local PostGIS databases all less than 2tb each and no table > 1M records (or if greater than 1M, simplified geometry at nodes > 1m apart), 60%-40%-10% WMS/WMTS/WFS requests, google cloud hosted servers, each 32 core, ssd drive cluster to 4Tb.
The bottleneck of qps appears to be Geoserver itself. (Styling, reprojection, all the niceties that come with it). I'm not advocating it is poorly written, but the heavier a car gets the slower it might drive.
If we replicate the wfs requests using GO or python +/- gdal to directly access postgis data we get faster throughput than geoserver (up to 1000 qps each instance or more, where PostGIS becomes the bottleneck).
The same goes for our homemade Java microservice based on PostGIS that creates pbf/mvt tiles from postgis- it, too, was very quick- at about 1000 qps.
Nginx for us performed slightly better than php (~110 qps vs ~89 qps), but this could be a result of a configuration of apache.
Where do we go from here? In all of our production use cases, for our users, serving miniature sharded sqlite/mbtile databases (vector or raster)... and maintaining them with custom code... was far more performant and scalable.
We may write a Java plugin for geoserver that pushes GeoWebCache TMS tiles into a Google Storage Bucket designed for slippy z/x/y calls... this way we could more easily maintain a tile pyramid with updates etc., using Geoserver tools.