Is there a way to keep GetCapabilities response time short and consistent?
Response time for WMS GetCapabilites request differs based on the time passed between two sequential GetCapabilites requests made to the server. For example, if the second request is issued within ~20 minutes of the first getCapabilites request than response time for the second request is usually around 300-600 ms.
When the time between first and second request increases to 20 min. to 2 hours than GetCapabilities response time increases to 12-16 Seconds. If the time between first and second request is more than few hours than it takes 2 to 5 Minutes to get a GetCapabilities response.I am testing with GeoServer Version 2.16.2, have approximately 150 layers, using a Limited SRS list (with 3 SRS), all vector data, mostly coming form PostGreSQL database and some local shape files. Is there a fix for this problem?
We don’t have any layer with Time Dimension. Some of the Tables are large but I don’t think GetCapablities request accesses to the Postgres tables for this request. We already know that this is related to the Java Garbage Collection. After the GetCapabilities Object is created for the first time (when you request first time after restarting the server or after it is disposed by the jave garbage collection process) than if you don’t keep requesting GetCapabilities every ~15 minutes than it will be compressed first and then within 2 hrs it will be disposed. After it is disposed it will take 1-3 minutes to re-create the full getCapabilities object. We are trying to use GetCapabilities request as configuration file (passed as a URL parameter) with an map application and unless we set up a scheduled task to request Capabilities every 15 minutes it will suffer form the performance.
Is there a way to keep GetCapabilities response time short and consistent?
Response time for WMS GetCapabilites request differs based on the time passed between two sequential GetCapabilites requests made to the server. For example, if the second request is issued within ~20 minutes of the first getCapabilites request than response time for the second request is usually around 300-600 ms.
When the time between first and second request increases to 20 min. to 2 hours than GetCapabilities response time increases to 12-16 Seconds. If the time between first and second request is more than few hours than it takes 2 to 5 Minutes to get a GetCapabilities response.I am testing with GeoServer Version 2.16.2, have approximately 150 layers, using a Limited SRS list (with 3 SRS), all vector data, mostly coming form PostGreSQL database and some local shape files. Is there a fix for this problem?
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this list:
Did you apply the JVM startup options froM the user guide? They are explicitly provided to keep objects in memory longer than is usually for a java program. You could try increasing the time limit and see what happens.
In geotools we take charge of the spatial reference system objects to more explicitly manage them in a cache. I am not sure if we take the same steps for the resource pool (which is caching some of the details needed for GetCapabilities).
Just to confirm, there is no such a thing as a “capabilities” object, the capability
document is written using a streaming xml API, meaning, it is pushed out bit by bit without
building a full in memory representation of it. There is no caching either.
What you are seeing might be GC (do you have a profiling session output to confirm?),
but it seems more likely that the capabilities writing is slowed down by other requests happening at the same time, or
that, if there is little to no traffic, that the JVM is swapped out of memory by the OS?
Cheers
Andrea
···
Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.ithttp://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.
Did you apply the JVM startup options froM the user guide? They are explicitly provided to keep objects in memory longer than is usually for a java program. You could try increasing the time limit and see what happens.
In geotools we take charge of the spatial reference system objects to more explicitly manage them in a cache. I am not sure if we take the same steps for the resource pool (which is caching some of the details needed for GetCapabilities).
Is there a way to keep GetCapabilities response time short and consistent?
Response time for WMS GetCapabilites request differs based on the time passed between two sequential GetCapabilites requests made to the server. For example, if the second request is issued within ~20 minutes of the first getCapabilites request than response time for the second request is usually around 300-600 ms.
When the time between first and second request increases to 20 min. to 2 hours than GetCapabilities response time increases to 12-16 Seconds. If the time between first and second request is more than few hours than it takes 2 to 5 Minutes to get a GetCapabilities response.I am testing with GeoServer Version 2.16.2, have approximately 150 layers, using a Limited SRS list (with 3 SRS), all vector data, mostly coming form PostGreSQL database and some local shape files. Is there a fix for this problem?
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this list:
Is there a tool that I can use to get a a profiling session output? Haven’t done this before.
System I am testing is Windows Server 2016 + Java 8 + GeoServer Version 2.16.2 + Apache Tomcat
*When the server restarts the first GetCapabilities response is always over a minutes (can go up to 4 minutes). We have approximate 10 different data-stores and some local shape files referenced by the geoserver. GeoServer log file indicates that server is making connection to all of the data files and Databases one by one before returning get capabilities response at the first time. After the first time it is in milliseconds. Until the resource cash is cleaned. when this happens the first request is returned within 12-13 seconds and following request are returned in milliseconds. I have to confirm but I think if GeoServer is not in use for 4-5 hours than GetCapablities response is in minutes at the first time requested.
Just to confirm, there is no such a thing as a “capabilities” object, the capability
document is written using a streaming xml API, meaning, it is pushed out bit by bit without
building a full in memory representation of it. There is no caching either.
What you are seeing might be GC (do you have a profiling session output to confirm?),
but it seems more likely that the capabilities writing is slowed down by other requests happening at the same time, or
that, if there is little to no traffic, that the JVM is swapped out of memory by the OS?
We don’t have any layer with Time Dimension. Some of the Tables are large but I don’t think GetCapablities request accesses to the Postgres tables for this request. We already know that this is related to the Java Garbage Collection. After the GetCapabilities Object is created for the first time (when you request first time after restarting the server or after it is disposed by the jave garbage collection process) than if you don’t keep requesting GetCapabilities every ~15 minutes than it will be compressed first and then within 2 hrs it will be disposed. After it is disposed it will take 1-3 minutes to re-create the full getCapabilities object. We are trying to use GetCapabilities request as configuration file (passed as a URL parameter) with an map application and unless we set up a scheduled task to request Capabilities every 15 minutes it will suffer form the performance.
Is there a way to keep GetCapabilities response time short and consistent?
Response time for WMS GetCapabilites request differs based on the time passed between two sequential GetCapabilites requests made to the server. For example, if the second request is issued within ~20 minutes of the first getCapabilites request than response time for the second request is usually around 300-600 ms.
When the time between first and second request increases to 20 min. to 2 hours than GetCapabilities response time increases to 12-16 Seconds. If the time between first and second request is more than few hours than it takes 2 to 5 Minutes to get a GetCapabilities response.I am testing with GeoServer Version 2.16.2, have approximately 150 layers, using a Limited SRS list (with 3 SRS), all vector data, mostly coming form PostGreSQL database and some local shape files. Is there a fix for this problem?
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this list:
Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.ithttp://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.
You may wish to consider the G1 garbage collector which uses several threads to cleanup and provides more consistent overhead (less stop the world moments, but more cpu use). It works well when using more memory like 4GB. Indeed I think they are making it the default for java now.
You may wish to consider the G1 garbage collector which uses several threads to cleanup and provides more consistent overhead (less stop the world moments, but more cpu use). It works well when using more memory like 4GB. Indeed I think they are making it the default for java now.
Did you apply the JVM startup options froM the user guide? They are explicitly provided to keep objects in memory longer than is usually for a java program. You could try increasing the time limit and see what happens.
In geotools we take charge of the spatial reference system objects to more explicitly manage them in a cache. I am not sure if we take the same steps for the resource pool (which is caching some of the details needed for GetCapabilities).
Is there a way to keep GetCapabilities response time short and consistent?
Response time for WMS GetCapabilites request differs based on the time passed between two sequential GetCapabilites requests made to the server. For example, if the second request is issued within ~20 minutes of the first getCapabilites request than response time for the second request is usually around 300-600 ms.
When the time between first and second request increases to 20 min. to 2 hours than GetCapabilities response time increases to 12-16 Seconds. If the time between first and second request is more than few hours than it takes 2 to 5 Minutes to get a GetCapabilities response.I am testing with GeoServer Version 2.16.2, have approximately 150 layers, using a Limited SRS list (with 3 SRS), all vector data, mostly coming form PostGreSQL database and some local shape files. Is there a fix for this problem?
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this list: