Introduction
Oracle recently announced a change in the pricing for the OCI Autonomous type services (ATP, APEX, JSON, etc.). The major change was that you now buy compute in units of ECPU rather than OCPU. Link to ECPU FAQ.
💡
Oracle tells us that performance-wise, 1 OCPU = 4 ECPUs.
This change means that according to the OCI pricing calculator, you can now provision an OCI APEX Application Development Service for less than half the previous cost, all be it with less computing power, memory, and storage. This is still fantastic news, as we can spin up a fully supported, fully backed-up APEX instance for around $138 a month.
As I had an OCI APEX Service, which I wanted to change from 1 OCPU to 2 ECPUs, I did some basic testing before and after to see how much performance I would lose for the cost savings.
Instance Configuration
Here is what my setup looked like before and after the change from 1 OCPU to 2 ECPUs:
| Option | Before | After |
| CPU | 1 OCPU | 2 ECPU |
| Storage | 1 TB | 256 GB |
| Backup Storage | 1 TB | 256 GB |
| Backup Retention | 60 Days | 30 Days |
| Autoscaling | Off | Off |
| OCI Load Balancer | 10 GB | 10 GB |
| OCI Vanity URL | Yes | Yes |
Test Setup
Test Data
I used the WA State EV car population dataset for my test data. The download creates a 36 MB CSV file from which I created a table with 18 columns and 150,483 records.
Test Cases
REST API 500 Records (Not Indexed)
- ORDS REST API that does a full table scan on all the columns in the table (SELECT * FROM TABLE). Because pagination is set at 500, it only returns the first 500 records. This produces a 233 KB payload.
REST API 91 Records (Indexed)
- ORDS REST API that does a filtered query on all the columns in the table. The query uses an index and returns 91 records from the table. (SELECT * FROM TABLE WHERE a=b). This produces a 45 KB payload.
APEX IR 50 Records (Not Indexed)
- This is a public APEX Page with a single Interactive Report querying all 18 columns from the table without a where clause (SELECT * FROM TABLE). The pagination is set to 50, so only the first 50 records are returned.
Test Approach
I used the Postman 'Run Collection' tool to run a Postman collection containing the above three requests. Postman will spin up a number of virtual threads, and each thread will execute each of the requests in the collection one at a time until the test is complete.
With Postman, you can use different load profiles to simulate different load types. I used three profiles to simulate three different load types in my testing.
Fixed 10 Profile
This simple test simulates ten users constantly cycling through the requests for 2 minutes.
Peak 25 Profile
This test simulates a fixed load of 5 users for 20 seconds. Then, steadily increase the load to 25 users over the next 20 seconds and hold for 40 seconds, and then steadily decrease the load from 25 to 5 over the next 20 seconds, maintaining a fixed load of 5 users for 20 seconds.
Peak 50 Profile
This test simulates a fixed load of 15 users for 20 seconds. Then, steadily increase the load to 50 users over the next 20 seconds and hold for 40 seconds, and then steadily decrease the load from 50 to 15 over the next 20 seconds, maintaining a fixed load of 15 users for 20 seconds.
Test Results
Unfortunately, per the OCI terms of service, I cannot publish benchmarks, so I cannot share the specifics in this post. I can, however, share my conclusions.
Throughput
Considering the performance is supposed to be half, throughput is not impacted as much as you would think. This is likely because these tests are not very compute-intensive.
Even with a peak of 50 simultaneous users, I never received a single error!
Response Times
With ten simultaneous users, average response times are almost the same when comparing 1 OCPU to 2 ECPUs.
Average Response becomes more erratic when we reach a 25-user peak load, with an average response time reduction of 25%.
Compute Autoscaling
Compute Autoscaling scales up to 3X your ECPUs (6 ECPUs in my case) when demand increases. I turned Autoscaling on and found performance was not much better than having just 2 ECPUs with no autoscaling. I think the reason for this can be found in this post from SQL Maria.
However, when Auto Scale kicks in, you do not get additional memory, or a higher degree of parallelism, since the goal of Auto Scale is to help you deal with a rapid increase in concurrent queries/workload. Once the demand drops off you want the system to go right back to what it was before.
As my tests do not really tax the CPU, it makes sense that Autoscaling has little impact.
Can you Break It?
The Postman load test tool only allows you up to 100 virtual users. I ran the test with 100 virtual users flat out for 1 minute, and although response times were erratic and throughput suffered, it soldiered on with zero failed requests!
Overall Conclusions
I am sure many of you want me to tell you how many users the APEX service with 2 ECPUs can handle. Unfortunately, I cannot do that 😔. I can, however, give you my thoughts on what these tests mean to me.
Memory
Oracle increases database memory as you increase the number of ECPUs. Reducing from 1 OCPU to 2 ECPUs would have reduced the database memory and impacted performance.
Consider how memory-intensive your workload is before going to 2 ECPUs.
🤫
It is a mystery to me exactly how much memory you get per ECPU?
Max Number of Users
You must be careful when testing with virtual users. In my peak load test, I simulated 50 users, all hitting go simultaneously for 2 minutes.
If you think about your APEX Apps, how many users all hit go simultaneously?
So, even though you may have 1,000 registered users, you may only need to accommodate ten active users simultaneously.
If your workload is CPU-intensive and you experience sporadic bursts of activity, consider using Autoscaling to keep your overall ECPU count (and costs) down.
Dynamic Actions
- When thinking about connections, you must consider dynamic actions. When you load a page with two dynamic actions (which have server-side callbacks / Ajax Requests), the page will make three requests.
Tune Your SQL
- In my testing, two of my queries were full table scans on a 150,000 record table. The query that used an index suffered much less from having 2 ECPUs. We could have expected a much higher throughput if I had tuned all the queries.
💪
When it comes to performance, you are in charge of your destiny. Writing slow queries will have a much more significant impact on performance than having an extra ECPU or two!
How Will I Use 2 ECPU Instances
I think 2 ECPU instances are a no-brainer for development and test environments.
I also believe they can be used in many production use cases, specifically those where you expect 20 or fewer simultaneous users (this could be thousands of registered users).
Other Ways to Save Costs
Reduce the storage allocation to save on storage costs.
Reduce backup retention days to save on backup storage costs.
Final Thought
🤔
Even though 1 OCPU = 4 ECPUs, 2 ECPUs are not twice as slow as 1 OCPU! This is excellent news for APEX developers who want to build production APEX Apps that are fully supported by Oracle but do not cost an arm 💪 and a leg🦵!
