地理位置和線程編號

我們使用的是Geoserver，並且在大量用戶的生產中出現性能問題。地理位置和線程編號

我們做了一些負載測試：250,150和20個線程。我們已經注意到，Geoserver在20個線程下比150個線程更好，而當線程數量增加（150或250）時，性能會下降。

這是正常的嗎？ Geoserver如何管理用戶請求？ Geoserver是否使用異步策略來管理用戶請求？

在此先感謝。

bsh

2011-03-15 bsh

聽起來很正常。線程（和cpu上下文切換）不是免費的，在某些時候，你將花更多的時間在切換線程周圍進行比實際做任何有用的事情。通常最好有更少的線程數（內核數量* 2通常是合理的），並與某種前端隊列相結合，這些前端隊列將接受連接並保留它，直到工作者閒置。

來源

2011-03-15 18:44:00

線程越多，服務器上的負載就越難。請參閱WikiPedia article on thrasing.

Geoserver的性能受許多因素影響。我的建議是看每一個，看看瓶頸發生的地方。

這裏有問題的列表，以設置正確的路徑：

什麼是本機的規格是多少？它應該有一個SSD。
您是否在生成您的瓷磚？還是他們預先播種？
- 如果他們你是預播種，那是跑步嗎？
  注意：預播可以幫助最大限度地減少生產中的系統。
什麼是您的數據源，如果PostGIS的，您使用的空間索引？
- PostgreSQL/postgis是在同一臺機器上嗎？
您生成的瓷磚類型有多少？

注意：您可能會生成不需要/使用的額外瓦片。
你使用GeoWebCache？

有了更多的細節，我可以幫助你。

來源

2016-03-15 18:24:33 theonlysandman

你確實意識到這個問題在2011年被問到了吧？雖然OP沒有接受答案，但它們可能並不處於同一狀態，所以他們不太可能提供更多細節......如果您提到了額外的細節可能會導致其他用戶，其他用戶可能會受益。 – Mogsdad 2016-03-15 18:42:08

下面是一些真實世界的用例統計數據;在生產中，針對爲戶外市場提供'谷歌地圖'風格用戶的移動/網絡應用程序，我公司已測試了各種配置（其中幾個由theonlysandman討論，這個問題的貢獻者），並且還支持通過Tyler Evans ，也是這個問題的貢獻者）。我們需要大於5000次請求/秒（'qps）的負載，並且由於我們的Geoserver實例無處不在，每個實例的接近100psps，我們需要橫向和縱向擴展到50多個Geoserver實例。

參數：大多數爲矢量源，本地PostGIS數據庫均小於2tb，並且沒有大於1M的記錄（或者大於1M，節點間距> 1m的簡化幾何），60％-40％-10％WMS/WMTS/WFS請求，谷歌雲託管服務器，每個32核心，ssd驅動器集羣爲4Tb。

qps的瓶頸似乎是Geoserver本身。（造型，重投影，隨之而來的所有細節）。我不主張它寫得不好，但汽車越重越慢，它可能會駕駛。

如果我們使用GO或python +/- gdal複製wfs請求來直接訪問postgis數據，我們將獲得比地理服務器更快的吞吐量（每個實例或更多，其中PostGIS成爲瓶頸時達到1000 qps）。

這同樣適用於我們的基於PostGIS的自制的Java微服務，從postgis-它創建PBF/MVT瓷磚，也很單觸在1000 QPS。對於我們來說Nginx的表現略好於PHP（〜110 qps vs〜89 qps），但這可能是apache配置的結果。

我們從哪裏出發？在我們的所有生產用例中，對於我們的用戶來說，爲微型分片數據庫（矢量或柵格）提供服務...並使用自定義代碼來維護它們......性能和可擴展性要高得多。

我們可能會編寫一個地理服務器的Java插件，將GeoWebCache TMS磁貼插入Google存儲桶中，這個存儲桶專爲滑動z/x/y調用而設計......這樣我們可以更輕鬆地使用更新等來維護磁貼金字塔， Geoserver工具。

來源

2017-08-15 18:47:05

地理位置和線程編號

回答

相關問題