we see an overall very improved performance for the CA Spectrum OneClick-Server task when running without option "java.compiler=NONE".
This option is set via ./tomcat/bin/catalina.sh for the Linux hosted OC-service; and via ./tomcat/bin/OneClickService.conf for Windows hosts.
Both files are ascii/native text files and with any editor you may remove this parameter / line.
Note - these configuration files will be re-created once the OC-service is reconfigured with the OC-webserver http/web-pages. This could be the case i.e. when subsequentially the memory setting for the OC-/Web-server is changed / increased. Futher more - we see the OC-server (better the java environment) will try to allocate more memory in general then. This may require to run the OC-server in a 64bit operational mode - and with increased memory settings.
What we saw from multiple feedback now is / best practice configuration:
- verify the currently allocated OC-server memory for the current OC-server operation (i.e. save 1.2GB allocation)
- stop down the OC-server
- enable the 64 bit mode operation for the OC-server (see $SPECROOT/tomcat/webapps/spectrum -> enable64tomcat)
- startup the OC-server
- configure memory to i.e. 3.5GB now (we did so up to 10GB with no problems at all) - consider to have a Host with sufficient phyiscal memory and do not set OC-server_mem > 50% OS.RAM.
- close the OC-webserver admin configuration pages - stop down the OC-server/service
- edit the catalina.out / OneClickServer.conf - find the -Xmx3500M setting (webserver memory) and remove the java.compiler=none parameter / line.
- save the current ./tomcat/logs/catalina.out | stdout.log file
- start the OC-server/service again and verify the startup time / improvements.
Overall - the java within OC-Tomcat now makes use of more memory as it tries to cache "compiled code" - which results in a higher memory allocation then before. Therefore it is required to increase the memory - and therefore the 64bit reconfiguration is recommended. Please consider to keep the defaults in case of very limited host memory configuration (you should have at least 4GB RAM - then not set -Xmx greater then 3GB for a standalone OC-server host).
Once the OC-server now runs, you may see higher memory allocation at time of active OC-console logons. We see up to 3 GB for around 50 logged on users when active in work within the OC-Console.
So - watching the OC-server memory allocation is much more vital then before - but this is normal. Once the users will logoff and the Java cache ages out, then you see memory is freed again.
At technical level we see this configuration (to run without java.compiler=NONE) is stable and will improve the overall processing performance for the OC-server tasks/threads. OC/SRM takes advantage of this - also big Locater searches (high use of Locater) and the logon procedure will become more efficient and run much quicker. The Restful API may become 10 times quicker.
As CA Spectrum is a multi-Tier applciation the improved "OC-server" performance may NOT solve all distributed Spectrum installation performance problems - important here is SpectroSERVER internal performance. You may see the "native" OC-server improvement via -> OC-Console -> Menu "Help" -> Debug Console - here find "Console Test" tab - and modify to 10,5,10 for the test-cycles. You may run this when the OC-server is at default - and then when it is in 64bit mode and without "java.compiler=NONE". The tests 0, 1, 2 top results are < 10ms, < 400ms, < 20ms ... seeing results > 150ms, >> 4000ms and >> 300ms can indicate overall performance problems.
Note: Once you apply a Hotfix-pack - or you reconfigure OC-server via OC-webpages/Administration you have to verify the configuration again. Cheers, Joerg