provide results under X ms latency for Y concurrent requests for endpoints that don't benefit from caching (i.e. search)

[bard]

Dependencies

• 20

• 21

• 39

If the above is not sufficient, other strategies to investigate could be, in ascending order of effort:

• increase number of machine instances
• disable full text search to verify its impact on latency and, if high, re-implement full text search with a native-code engine (e.g. xapian or sphinx)
• test whether async I/O makes a difference

To benchmark

Use ab (ApacheBench). Use gitcoin-search-dev.fly.dev, not the cloudfront URL, otherwise responses after the first will be cached. Choose the number of concurrent requests and latency. E.g. for 4 concurrent requests and 800ms latency, run:

$ ab -n 100 -c 4 'https://gitcoin-search-dev.fly.dev/search?q=education'

Inspect the last lines of the output to see how many requests were satisfied within the desired time:

Percentage of the requests served within a certain time (ms)
  50%    748
  66%    753
  75%    758
  80%    761
  90%    773
  95%    797
  98%    811
  99%    858
 100%    858 (longest request)