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.

NREL / api-umbrella

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