A client is in the process of selecting the specifications of the ideal server on which to run Rhythmyx. The VM it’s currently on is just not cutting it. Essentially we want to come up with the ideal specification to provide to the supplier, while initially running with no further license obligations. I wonder if anyone could comment on the following for me, along with any other suggestions you may have?
They have a single CPU license, so intend to use a single multi-core processor in a server with at least 2 processors should the need arise to upgrade to a multi-CPU license. However they will initially need to update their single CPU license to handle a single multi-core CPU. I understand this has no license implications? Also, are there any significant benefits in Rhythmyx [6.7] (real or theoretical) going from a quad-core to an 8-core processor?
Secondly, since this server will only be running Rhythmyx, disk space is not an issue so I would suggest going for lower capacity ultra-scsi for speed - sensible?
The operating system is the next question, together with memory. Since the JVM can only run with 1.5Gb, does this improve with a 64-bit OS or a multi-core processor? Actually will Rx run any better or worse in a 64-bit environment?
I’m not greatly knowledgeable about hardware so your input would be much appreciated.
In regards to the number of cores in my experience it has very little effect unless you upgrade to 6.7 which has multi threaded publishing (you don’t need a special licence) we have found that publishing is a lot faster using multiple cores we run 6 threads on an quad core dual processor machine. Before 6.7 Rhythmyx publishing is single threaded so additional processors won’t make much difference, a while back we were experiencing performance issues especially around publishing and trailed a multiprocessor licence on 6.5 which had absolutely no effect.
We also run 64bit linux which does allows you to assign up to 3GB to the java heap but I found assigning any more than 1.5G ran into garbage collection issues.
We have some new hardware which has 16 available cores so it will be interesting to see what performance increase we will get by increasing the number of publishing threads
It certainly does, thanks. I thought there was a setting to optimise garbage collection but will check that out - but essentially it seems there’s no point going for massive amounts of memory in any case, and putting as much processing power behind the system as possible is naturally good. We’re also hoping to improve dire preview assembly times on the current set-up (upwards of 10 seconds a page to many times that, when my laptop running the same system in a VM manages 2.5 - 5 seconds). Anyway, thanks for that.