concurrency config guidance for readme?

[jjb]

I put together the below for #3 but then thought maybe the project would prefer to not attempt to handle such discussion and guidance because it would be a challenge to be thorough and stay up to date.

If you think the below looks valuable i can do another PR adding it to the readme.

---

Concurrency Configuration

Figuring out the values of the above two numbers varies by platform. Here are
some guidelines to go by. Note that there are many factors involved in
configuring your concurrency not covered here. The methods below are just
a starting point.

MRI

Because MRI doesn't have "real threads", ideally there would be at least one worker
for each CPU core. Heroku 1x, 2x, and Performance-M dynos each have 8 cores. Performance-L
dynos have 2 cores.

It's often not possible to have a worker per core, because of memory constraints.
For example, a medium to large rails app on a Heroku 2x dyno will take up 300-550 megs, which
alows for only running 1-3 workers.

Start with 1 worker, observe your app's behavior, then go up from there.

Even though threads on MRI aren't "real", they are still valuable because they
allow for concurrency when a thread is waiting on IO, which happens very often
in a web application. Unfortunately, figuring out how many threads to run is not cut and dry,
but is possible. First, start with the default 5 threads. Then, use the above-described
method to figure out the max number of workers you can run. Then, increase MAX_THREADS
and observe if there is increased performance in your app. Keep increasing the
threads until you no longer observe inmproved performance in your app.

n.b. that because you probably won't be running a worker per core and because more threads
won't be used by all the cores, you cannot use CPU load as an indicator of if you
are running enough threads.

If you are only running a few dynos and don't particularly have scaling problems,
and you don't have an easy way to observe performance changes, then you can just
leave threads at the default 5 and call it a day.

JRuby, Rubinious

These platforms have "real" threads, so they do not benefit from workers. puma-heroku
detects that you are on these platforms and runs only one worker,
ignoring the WEB_CONCURRENCY variable.

To configure the concurrency on these platforms, increase MAX_THREADS until the
load average on your dyno is around the same number as the number of cores. If your load
max and load average are very different, then you may want to do a deeper dive into the different
types of requests your app handles to see if some have worse performance than others with different
configurations.