Page History

Java Virtual Machine (JVM) Tuning

Java version
Servoy supports both Java 5 and Java 6 (for the serverApplication Server, the clients Smart Client and developerServoy Developer). As Java 6 has numerous performance improvements, so it is preferred over Java 5.

When If the hardware of the in which Servoy is running is 64bit, make sure to also run a 64 bit Java Virtual Machine. When in doubt which version is used, check the Servoy Admin page, under "Servoy Server Home" > "Servoy Server Status" > "JVM Information":

• 64 bit: java.vm.name=Java HotSpot(TM) 64-Bit Server VM
• 32 bit: java.vm.name=Java HotSpot(TM) Client VM

Java Virtual Machine Server mode
Java has 2 distinct operating modes: client mode and server mode. When running in server mode, the startup of the Java process will take longer and initial execution of code will be slower, but after a while the application will perform faster. The server mode is best suited for the Servoy Application Server.

...

# Java Additional Parameters
wrapper.java.additional.1=-Djava.awt.headless=true
wrapper.java.additional.2=-Duser.dir="C:\Users\pbakker\Desktop\tmp servoyServoy\application_server"
wrapper.java.additional.3=-XX:MaxPermSize=128m
wrapper.java.additional.4=-server

...

The maximum heap size setting is set located in {servoy_install}/application_server/servoy_server.sh/.bat, through the "Xmx" setting.

When the Application Server is started as a Service through the setting can be found in {servoy_install}/application_server/service/wrapper.conf, by the name of "wrapper.java.maxmemory".

...

• The actual used memory is >= 70% of the specified maximum. The actually used memory can be found on the main page of the Admin page, under System Information, like: Heap memory: allocated=549184K, used=371473K, max=699072KWhen there is plenty of free real memory available on the OS level, Servers in general just run faster when not memory constraint. (When 2Gb free real memory is left, just add the 2Gb to the JVM max memory. It will stays unused otherwise, the JVM will not take more memory then assigned ever.)
• When the expected client load will exceed the maximum: As a rule of thumb:
  • Smart Client: assume a memory usage of about 600kb for each Smart Client. NOTE: When the Servoy HTTP Tunnel is used, assume 900kb per Client.
  • All other type of Clients (Web, Headless, Batch): the required memory for each client depends on the size and design of the solution, but should be in the order of magnitude of a couple of Mb per Client.
• When there is plenty of free real memory available on the OS level. Java processes in general perform better when not having memory constraints. For example, when 2Gb free real memory is left, add the 2Gb to the maximum heap size. The Java process will only take what it needs.

Database Connection Pool Tuning

Databases have a max connection poolsize to prevent memory problems, but the default 10 can be too low when using many clients on 1 server.
As rule of thumb, if the active connection is > 70% of the max then set the max higher, its however not advised to have more then 30 connection max. (since databases them self have limits on how much they can handle, postgress for example default 40 max)
The idle connection parameter is just for efficient memory usage, when allow many idle more memory is occupied when idle, low idle means more connections have to be created (which is expensive time wise)

...

The Servoy Application Server uses a pool of database connections per configured Database Server. 

The maximum number of active and idle connections within a pool is configurable to preserve resources. For example, a single connection could easily take up a couple of Mb, both on the Servoy Application Server side, as well as on the database engine side.

The settings are configurable on the Servoy Admin page, under Database Servers:

• Maximum connections active: the maximum number of connections that can be created within the pool.
  If set too low, handling requests towards the database might slow down, as one request needs to wait until another request is processed and the connection is returned to the pool
  If set too high, the exceptions might occur if the database cannot handle that many concurrent connections or if more memory is required than is available
• Maximum connections idle: the maximum number of inactive or idle connections in the pool
  Active connections that are done processing a request are returned to the connection pool as idle connections. If the number of idle connections goes over the maximum, the connections are removed.
  As instantiating new connections takes time, the value shouldn't be too low. On the other side idle connections take up resources, so the number shouldn't be too high either.

The maximum number of active connections is also limited by the maximum number of connections the database itself is configured to allow. For the bundled PostgreSQL database engine, the maximum is 100 connections. However, these 100 connections are for all connections made to the database instance. This means that if there are multiple Database Servers defined on the Servoy Application Server which are all hosted on the same database instance, the max. 100 connections are for all Database Servers combined. This must be taken into account when setting up the maximun number of active connections.

By default, the maximum active connections setting is set to 10. This could be too low when serving may clients from one Application Server or when the clients do many requests to the database. As rule of thumb, if the actual used active connection regularly goes above 70% of the maximum a higher number of maximum active connections should be configured.

Database Tuning

When experiencing performance issues, analyse the "Performance Data" page of the Servoy Admin page. This page provides an overview of all queries fired at the database.

At any given time regular SQL statements (Type = Relation, Load foundset) should have an average execution time below 0.5 seconds. 

The performance data is sorted by the total time taken to perform the query, being the result of the average time * number of executions.

Especially for SQL statements that are fired often and take up significant time it should be checked if it's possible to optimize the database, for example by creating the relevant indexes. 

Web Client Settings Tuning

servoy.webclient.templates.use_local_ids

...

At all times try to keep the Server log free from javascript application errors/excpetions, all application exceptions point to possible problems inside the application!.

• Out of memory errors means the heap size is configured to small.
• Nullpointer errors indicate Servoy codebase problems, incase these are noticed file a support case containing the log entry.
• Network error are only listed as non critical (orange) which may point to (possible) networks (config) problems, when many errors are continuous listed these should definitely be investigated.