Bad Performance compared to Promise.all([...fetchPromises])

[terencechow]

I have a /graphql route and a /nongraphql route.

I am testing a graphql query that resolves 13 GET requests to my backend service. It looks something like this:

query MyQuery ($id: String) {
    project(id: $id) { projectName, projectId, etc }
    account(id: $id) { accountName, acountId, etc }
    ... etc 11 other fetch queries
}

Each inner query is simply a http GET request. (i.e. fetch(url))

Alternatively my /nongraphql route looks like so:

function nonGraphQLRoute(req, res) {
    Promise.all([
         fetch(http://backendservice/projects?projectId=3),
         fetch(http://backendservice/accounts?projectId=3),
         ...etc 11 other fetch calls
    ])
    .then(results => res.send(results))
}

Note that the fetch functions in my nonGraphQL route are identical to the fetch functions in my GraphQL route.

Therefore the only difference between the two routes would be what GraphQL does. My apache benchmark tests indicate the nonGraphQL route is 100% faster then my graphQL route. Specifically for the 95% of requests nonGraphQL route returns within 239ms, a very manageable number. However my GraphQL route returns 412ms, obviously a very unacceptable number.

What is GraphQL doing that slows this route down so much? What can I do to speed up performance

Apache benchmark tests follow:

nonGraphQL results:

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Finished 250 requests


Server Software:        restify
Server Hostname:        localhost
Server Port:            5000

Document Path:          /nongraphql
Document Length:        14826 bytes

Concurrency Level:      5
Time taken for tests:   9.655 seconds
Complete requests:      250
Failed requests:        0
Total transferred:      3743500 bytes
HTML transferred:       3706500 bytes
Requests per second:    25.89 [#/sec] (mean)
Time per request:       193.108 [ms] (mean)
Time per request:       38.622 [ms] (mean, across all concurrent requests)
Transfer rate:          378.62 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:   107  192  26.4    189     307
Waiting:      107  191  26.3    188     306
Total:        107  192  26.4    189     307

Percentage of the requests served within a certain time (ms)
  50%    189
  66%    197
  75%    202
  80%    206
  90%    220
  95%    239
  98%    279
  99%    288
 100%    307 (longest request)

graphQL results:

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Finished 250 requests


Server Software:        restify
Server Hostname:        localhost
Server Port:            5000

Document Path:          /graphql?query='...omitted...'
Document Length:        13645 bytes

Concurrency Level:      5
Time taken for tests:   16.145 seconds
Complete requests:      250
Failed requests:        0
Total transferred:      3448250 bytes
HTML transferred:       3411250 bytes
Requests per second:    15.48 [#/sec] (mean)
Time per request:       322.902 [ms] (mean)
Time per request:       64.580 [ms] (mean, across all concurrent requests)
Transfer rate:          208.57 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.4      0       2
Processing:   104  321  58.5    317     511
Waiting:      104  287  57.4    290     510
Total:        104  321  58.5    317     511

Percentage of the requests served within a certain time (ms)
  50%    317
  66%    344
  75%    352
  80%    358
  90%    384
  95%    412
  98%    499
  99%    500
 100%    511 (longest request)

[leebyron]

I would suggest profiling your server to understand where the time is being spent.

Are you constructing a schema for each request? Are the queries persisted or is there some time being spent uploading or parsing bytes? Are your backing reads to a backend service batched in any way?

There are lots of things which could be causing a slow down, and unfortunately there is no silver-bullet answer, you'll just need to investigate.

If while doing so you happen to come across a performance bottleneck - please report it so it can get proper attention, or even better send a PR to help speed things up.