I am looking for some advice and ideally facts around the relationship between the server architecture the CM System is installed upon and the performance output of the CM System Application.
Though it seems fairly obvious that the more powerful and robust the architecture so too will be the application I need to gather evidence for a business case in support of upgrading our CM System server installation.
Currently we have our CM System (6.7.0 Build 200906P01 (3370) [CMS-155]) application installed on a virtual server running Windows Server 2003 Standard Edition SP2 (32bit). This in turn connects to a SQL Server database, which is on a shared server, and also a shared instance with other database catalogues.
We have been observing intermittent slow down in the CM System application and it is my belief that this is due largely to other applications that share our servers challenging the CM System for use of resources.
I am proposing that we should change our architecture to dedicated physical, single tenant, servers and use a 64bit operating system. My assumption is that we will see a far more stable and indeed faster performance of the CM System.
What I need is some evidence and or case study that such a change in architecture is both logical and sensible and will improve the performance and stability of the CM System Installation. If you were able to provide any information to support my business case this would be most appreciated.
What is the current memory allocation for both application and database instances? Have you identified when CM System slows down such as during publishing, several users connected at once, etc…?
Have you read through other forum threads that talk about increasing the java heap space for CM System? You may also want to monitor your SQL Server to gauge its performance.
Hi Riley the slow down occurs randomly and not during any particular of CM System use which is why I believe it is the server archtecture and not the software that is to blame. We have tweaked the Heap Space memory allocation to the maximum it can be on a 32bit windows 2003 server. What I am interested in is VM ware verse physical server hardware and proof that one is more benficial to performance that the other.
I can’t say that I have seen a major difference between the two if I were to configure a virtual instance the same as my physical instance. May need to start profiling your CM System instance using a tool such as JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html).
In general you will always see a slight performance improvement on dedicated hardware, but in many modern I.T. infrastructures that is just not possible or cost effective to go dedicated. We use Virtual Machines almost exclusively internally at Percussion.
There are a couple of things that might cause an intermittent slow down like this. Some are in the software and some could be related to the server environment. One question is are you experiencing the slowdown in the user interface, with publishing times, or both?
I’ll list out a few things I usually check in no particular order.
1.) Check the health of full text indexing and clear any errors from the search index queue table. Indexing occurs on a background thread and large amounts of errors or collections of documents added in batch could cause a slow down. You can also disable full text indexing if you are not using the feature.
2.) Check the scheduled tasks in the Admin->Scheduled Tasks for an edition or purge task with a bad schedule. Meaning if a relatively large edition is being kicked off at peak editorial hours on a schedule this could be a cause. The task scheduler happens in the background. I have also seen these managed outside of the product in the operating systems task scheduler, typically cron on *nix based systems or AT on windows. Check those for a scheduled edition or backup.
3.) Backups. If a database backup schedule or server backup schedule is coinciding with your slowdowns it could be related to that.
4.) A competing job on the database server. If the database server gets slowed down by heavy processing like a schedule bulk load on an unrelated database, you may see that slowdown in the product as it is relying on the database.
5.) On the Rhythmyx server, make sure things like Virus scanners are excluding the Rhythmyx directories especially the tmp, temp, and work directories. During publishing this can can cause a slowdown as the system is typically writing out a high volume of files. Operating system Indexing services like Windows search can also cause problems like this if they are indexing the installation or temp directory.
6.) On the VM server cluster monitor IO/CPU loads when you are seeing the slowdown. That can help to isolate troubleshooting to your VM instance or to another competing instance in the cluster.