Twproject’s installer will set some default configuration of the web server and database usage – which could need to be fine tuned for each particular environment.
This section assumes some technical IT competence.
Java memory usage
Twproject is a Java application, and it runs in Java web servers – by default Tomcat is hungry for memory; fortunately server memory is really cheap these days.
The server where Twproject is running should have at least 2GB of memory, so that Ttwproject can run in at least 1GB.
If you want to go beyond the 1GB limitation, you should not use Windows servers, as these have notoriously contiguous memory limitations in running Java. Use a 64 bit Linux server and you will have no limitations about the amount of memory you can give to Java.
It must be said that for most usage scenarios 1GB of memory for Twproject is more than sufficient.
A typical symptom that memory configuration must be tuned is when you get “java.lang.OutOfMemoryError: Java heap space” errors. In this case the most likely culprit
The best way to be sure that the memory configuration changes are in use in Twproject is to launch the “system check” page (admin -> system check) and verify the memory parameters there reported. For example, before:
To do the changes: instructions for different OS follow.
On a Windows server: open a DOS command interface:
Change -XX:MaxPermSize to 384m or more and
changed maximum memory to 1024MB or more
and after restarting the Twproject service:
That’s it!
For additional information on Tomcat service see:
https://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html
On Linux: open the twprojectLinux.sh script, and change the -Xms128m -Xmx384m settings to a higher range.
On OSX: if you are launching by script by hand, open the twprojectOsx.sh script, and change the -Xms64m -Xmx128m settings to a higher range. If you are launching Twproject as service, change in [twproject root folder]/launchdScript.sh the line “export JAVA_OPTS=-Xmx512M $JAVA_OPTS” (if it is #export JAVA_OPTS=-Xmx512M $JAVA_OPTS, remove the #).
Permission Cache
By limiting the number of complete and frequent security-related queries, Twproject manages a cache that is allowed to reuse the security test in the last “maximum age”. Changing your roles could therefore have a slightly delayed effect and indeed, when there is a tuning of them it is advisable to turn off the cache.
Enabling more database connections
By default Twproject uses a database connection pool, called Proxool (http://proxool.sourceforge.net/).
This pool has a built-in monitor, which you can enable by modifying the provided web.xml (WEB-INF/web.xml). Add among the servlets configuration
<servlet> <servlet-name>proxool</servlet-name> <servlet-class>org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class> </servlet>
And in the servlets mapping
<servlet-mapping> <servlet-name>proxool</servlet-name> <url-pattern>/proxool</url-pattern> </servlet-mapping>
Restart Twproject, and call
[your Twproject URL]/proxool
Getting:
To enable more db connections, you have to set in config.properties the poolMaxSize property:
## connection pooling: optionally set max size poolMaxSize=50
Clustering the database
Twproject uses a very simple JDBC connection to “a database”. The entry point provided can of course be clustered: for this you must refer to your database specific documentation.
Clustering the web server
Twproject can be clustered also as application: in case of load balance, so called “sticky sessions” must be enabled. The only conflict that could be raised in case of application clustering is in the scheduled jobs. Twproject has a built-in mechanisms that enabled only one node in the cluster for job scheduling. Of course we assume that all nodes in the application cluster will be pointing to the same database entry point instance (eventually clustered too).