This is a multi-purpose machine I use for lots of demos, testing & internal systems – so it’s pretty busy.
- 4x Core
- Running lots of apps (Apex, DB, SVN, Wiki, Apps Dev, Essbase, EAS, OBIEE, VA, Publisher). Running >80% Memory Utilisation.
VM on AWS
I was kindly granted temporary access to a VM version of OACS – it’s the one you get access to when you run a demo via demo.oracle.com. I added a little more horsepower to it since I wanted to run the RDBMS and the BI stack as well to test out some other functions:
- 8x Core
- Running full OAC Stack (DB, Apex, Essbase, BI, DVCS)
OAC on Oracle
This was running the a “full” #OracleAnalyticsCloud setup. I used the minimum specification I could. I didn’t start up a BI node at all – for this test, I didn’t need it. So we were running a RDBMS node and a seperate Essbase node only.
- 1x OCPU Essbase
- 1x OCPU RDBMS (2 cores per OCPU, btw)
I have tested ASO calc performance on 2x POC cubes for one of our customers.
- Both cubes are ASO Unicode.
- Neither are particularly optimised.
- Approx 100 million data points loaded
- All versions across the servers are identical
execute aggregate process on database 'ABI_Reg'.'ABI_Reg' stopping when total_size exceeds 10;
You can see I set the aggregation factor to be quite high – these cubes have a number of flat dimensions, so making it do a bit more pre-aggregration helps enomrmously.
- We’d expect the AWS OAC VM to be the fastest (it has more cores) – and probably the OAC & on premises servers to be similar (the on-premises server is pretty busy, even though it has more cores).
- Performance is roughly as we expected – OAC is in the ballpark of what we usually see.
- With Oracle, 1x OCPU is 2x Cores.
- When sizing an OAC Essbase Node, use the same established on-premises sizing guidelines to ensure you have enough CPU & Memory to calculate the cubes. Particularly relevant if there are lots of users, or big cubes that need calculating.
- The other learning point is that these cubes need tuning. 🙂