I apologise for ressurecting this thread (and the wall of text that follows), but I have some results from testing CSEs over the last year or so in the physical and cloud space.
Some context ... at my current site we have a large application model and some utility models.The application model has 5,576,437 objects and the utility model tested has 198,819 objects.
It is not a CBD based site ... there are no Spec Types. Everything is referenced by either an Entity type or Work Attribute Set.
We were asked to investigate speeding up the migration and build process on the CSE ... as in C# everything is treated as static, so large calling chains caused rebuilds. Not being a CBD site also meant that changing key Entities flowed onto large impacts on the model, hence causing lengthy migration and build times.
So over the last year we tested four (4) different CSE configurations to speed up the process.
Config A - Production CSE (E7 2850 x 2 - 2.0 GHz) - SSDs in RAID 10 for OS/Database and fibre SAN connectedConfig B - Amazon Cloud (C3.2xlarge - E5 2680 2.8 GHz) - 50Mb/s diskConfig C - Amazon Cloud (C3.2xlarge - E5 2680 2.8 GHz) - 100Mb/s diskConfig D - Future CSE (E5 2643 x 2 - 3.5 GHz) - SSDs in RAID 10 for OS/Database and fibre SAN connected.
A B C D
Model Copy (App) 5:30 N/A N/A 2:10 (H:MM)
Model Copy (Util) 0:09 0:08 0:06 0:05 (H:MM)
Migrates had similar behaviour (just don't have the timings at hand).The app model was not copied on the cloud server as it was taking a long time and the tests on the smaller model were showing the trend for performance and I/O.
I/O was the big factor in the tests. We observed on the physical servers that the I/O would peak over 700Mb/s as the objects were copied into memory, and then stablise out until the process finished. The cloud servers peaked at their disk limits (50Mb/s and 100Mb/s) and stayed there for a long time before coming down to a level similar to the physicals.
CPU does have a factor in the CSE processes. However, we saw larger gains due to faster CPUs in the generate and build processes. You can also see with the larger amount of objects to process, CSE config D had larger gains due to I/O and CPU.
If you were to increase the speed of the I/O available to the CSE I predict that the cloud servers would have got closer to the timings found on Config D ... but the TCO of the faster storage in the cloud was starting to factor considerably less favourably to having a physical server onsite.
While this is more cloud vs tin ... virtualization can have the same drawbacks and configuration is the key. I have observed a trend over the last few sites I have worked at that the development platform is not seen as 'production' and for less compute resources (infrastructure, software, personnel, etc) being available because it is only developers that have to deal with it. However, it is all about risk vs reward. What do you add to the development and testing effort if you have resources waiting for processes to complete? How can you aid the agility of your development process by having a faster more efficient CSE?
IMO, over all the CSEs I have configured with differing versions of Gen ... I am happy with what will soon be deployed at my current site as it will make a considerable difference for the current development process.
Some recent performance figures.
HypervisorHyper-V 2012 R2
Virtual MachineWindows 2012 R2 StandardIntel Xeon E5-2662 2.2GHz1 slot 4 processors4GB memory
Local 10K 6Gbps SAS drives RAID 5
SQL Server 2014 Standard
CSECA Gen r7.6 GA
Object cache 1000 (default)
obj_model_id #------------ ----------- 1 77341 77261 77470 154650 1567379 1721912 3015907
Upload obj_model_id hh:mm:ss------------ ----------- 1 00:08:08 77261 00:08:11 154650 01:37:58 1721912 02:58:41
Downloadobj_model_id hh:mm:ss------------ ----------- 1 00:06:10 77261 00:06:03 154650 01:28:24 1721912 02:35:56
No other work on the machine. CPU flat-lined at one processor equivalent for the duration of each upload and download. Did not check I/O.