Geoserver和线程编号

Question

我们正在使用Geoserver，我们在生产中遇到了大量用户的性能问题。

我们已经进行了一些负载测试：250,150和20个线程。我们注意到Geoserver使用20个线程比使用150个线程更好，并且当线程数增加（150或250）时，性能会降低。

这是正常的吗？ Geoserver如何管理用户请求？ Geoserver是否使用异步策略来管理用户请求？

提前致谢。

BSH

Answer 1

听起来很正常。线程（和cpu上下文切换）不是免费的，并且在某些时候，你将花费更多的时间来绕开关线程而不是实际做任何有用的事情。通常更好的是拥有更少数量的线程（核心数量* 2通常是合理的），并结合某种前端队列，它将接受连接并保持它直到工人空闲。

Answer 2

以下是您的一些实际用例统计信息;在生产中，对于为户外市场提供“google-maps”风格用户的移动/网络应用程序，我的公司已经测试了各种配置（theonlysandman讨论了其中的几个，这个问题的贡献者），并且还支持Tyler Evans的观察，也是这个问题的贡献者。）

我们需要大于5000个请求/秒（'qps）的负载，并且由于我们的Geoserver实例无处不在，每个接近100 qps，我们需要水平和垂直扩展到超过50个Geoserver实例。

参数：主要是矢量源，本地PostGIS数据库均小于2tb且没有表＆gt; 1M记录（或者如果大于1M，节点上的简化几何图形>相隔1米），60％-40％-10％WMS / WMTS / WFS请求，谷歌云托管服务器，每个32核心，ssd驱动器群集到4Tb。 / p>

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 Storage Bucket ......这样我们就可以使用Geoserver更轻松地维护带有更新等的磁贴金字塔工具。

Answer 3

线程越多，服务器上的负载就越难。见WikiPedia article on thrasing.

Geoserver的性能受到许多因素的影响。我的建议是看每一个，看看瓶颈发生在哪里。

以下是设置正确路径的问题列表：

1. 您的机器有哪些规格？它应该有一个SSD。
   

2. 您是否在路上生成瓷砖？或者他们是预先播种的？
   

   • 如果他们正在播种，那是在运行吗？
     注意：预播种有助于锤击系统，因此最好在生产之外完成。
     
     

3. 您的数据来源是什么，如果使用postgis，您使用的是空间索引吗？
   

   • PostgreSQL / postgis在同一台机器上吗？
     
     

4. 您生成了多少种瓷砖？
   
   注意：您可能会生成您不需要/使用的额外瓷砖。

5. 您使用GeoWebCache吗？
   

有了更多细节，我可以帮助你。