Changing the number of cores on nginX and gatekeeper settings doesn't affect the API-Umbrella performance

Hi,

So I am investigating the use of api-umbrella for a product and I am noticing that the API is always bottlenecking to the same values when running an apache -ab test.

My -ab test is:

ab -c < a value between 10-100, in increments of 10> -t 300 <url to my proxy or control>

To characterize the API-Umbrella's performance over 5 minutes over 10-100 concurrent users.
I am also characterizing the cpu usage and ram usage using the linux commands:

sar and sar -r

on the machines that host my API-Umbrellas

My Setup:
1 CentOS 7 VM that hosts a local MongoDB server
1 CentOS7 VM that has every other component (Elasticsearch, router, etc) according to the deployment documents

I've done three different trials:

• RUNA at 1 CPU Core, 4GBs of Ram
• RUNB at 4 CPU Cores, 4GBs pf Ram
• RUNC at 8 CPU Cores, 4GBs of Ram

RUN A: had about 30-50% CPU usage and 40-50% RAM usage
RUN B: had about 15-25% CPU usage and 40-50% RAM usage
RUN C: had about 5-15% CPU Usage and 40-50% RAM usage

I've explicitly set the core values in the api-umbrella.yml with

gatekeeper:  
  workers: <number of CPU cores>  
nginx:  
  workers: <number of CPU cores>  

I'm observing the following:

• The API is maxing out at similar request/sec values for all core settings (e.g. for all settings for all runs. I see that the proxy will always max out at a value around 150 req/sec)
• The absolute CPU and RAM usage remains the same for api-umbrella despite setting the nginx and gatekeeper cores explicitly in the .yml file
• My baseline (hitting the service I'm hosting directly without the proxy) is able to handle well above 150 req/sec in my control runs. (going to 300+ req/sec)

I have explicitly restarted the service between my changes, and recorded the same observations over 3 times per my proxy settings.

Typically, when an application maxes out a X requests per second, it’s because of CPU pressure, memory pressure or I/O (disk/network) pressure. Since my observations lead me to believe it’s not CPU or memory bound, I think it might be I/O bound - perhaps by the ElasticSearch component?

However, before proceeding any further, I would like to see if anyone has other ideas - perhaps a configuration setting I missed that is limiting things, or any other ideas.

Start with the deployment documents and api-umbrella.yml, checking the nginx and gatekeeper worker settings used in the reported runs. Reproduce the ab tests while collecting sar and sar -r data across the 1-, 4-, and 8-core cases, then inspect the Elasticsearch and MongoDB components. Done should be a documented bottleneck or configuration cause, with supporting measurements.