если грубо, то посмотрите сколько у вас одновременно в пике соединений, прибавьте 20-30% и вот вам стартовое кол-во воркеров fpm.

даже в рамках 8gb оперативки?

8gb это вообще-то много...

2к rps мало что говорит про память, тут больше важно как долго будет отрабатывать ваши запросы,
то есть сколько висящих одновременно запросов..,

наример если запросы в среднем будут по 50мс, то одновременно будет только 20 запросов работать... пускай они едят по 100мб каждый (это вообще-то много очень), получится, что всего им надо 2гб...

Недавно был опыт настройки php-frm

На настройках по умолчанию:

pm.max_children = 5

Сервер мог утилизировать 5 ядер процессора, что ограничивало возможности вертикального масштабирования. На 5 ядрах получалось 800 RPS. На 8 -- 1000+ RPS.

Обратите внимание на этот параметр в
/etc/php/7.2/fpm/pool.d/www.conf

И можно почитать инструкцию:
https://geekflare.com/php-fpm-optimization/

И конкретно для моей системы для 2к rps понадобилось бы два сервера php-frm или 16-20 ядер на одном сервере. Но они бы не помогли -- в производительность базы данных бы упёрся

Nginx + fpm в дефолтном конфиге обоих при 4х ядрах и каком-нить 3,5Гц, при скрипте echo "OK"; с кип элайв выдаст тыщ 60-80 rps, а без кипэлайва тыщ 14-18.
Говорю на вскидку, но не думаю, что сильно ошибусь.

Так что думайте сами во что вы упретесь с 2к... Ессно это будет тяжесть скриптов, базы и другие cpu/latency, но не nginx+fpm.

Имейте ввиду, что cpu/iops'ы ваших скриптов и баз запущенных на том же серваке будут отнимать их у nginx/fpm... Так что ессно, если последним остаётся 1/10 cpu, то и скорости будут соотв...

Вы сильно недооцениваете производительность СУБД, как и многие, для них десятки тысяч RPS - это давно норма. Все пляски с бубном вокруг кэша, масштабирования репликами и прочего в 99.99% уходят после того, как люди начинают понимать как работать с инструментами, ну, или не уходят и от этого страдает бизнес в котором они работают.

Хотел подсветить, что настройкой одного лишь php-frm не обойтись.

Если сможете помочь автору вопроса в возможном ускорении бд (думаю, MySQL), то помогите. Видимо, у вас есть опыт кеширования БД. На моей практике тысяч RPS для БД (Postgres) не достигал из-за скорости диска, даже при хороших индексах

Это смотря какие запросы. Если запросы по уникальному индексу и данных столько , что большинство из них поднимитесь в буферный кеш, то тысяча rps - это реально , а если запросы такие , что нужно делать , например 10 физических чтений по 8k, то это уже наврятли .

Вы сейчас вот тут просто создаете те самые "мифы" тыкая пальцем в небо без понимания вопроса.

Поделитесь своим опытом, что за БД, какой характер нагрузки, сколько "десятков тысяч RPS" вам лично доводилось выжимать без " пляски с бубном вокруг кэша, масштабирования репликами и прочего"  (т.е. на одной машине?).  Это реально интересно.

PostgreSQL не самый свежий xeon на 8 ядер + гипертрейдинг, 32 gb памяти 80к rps. 1 запрос это вызов процедуры на Pl/pgSQL с относительно увесистой логикой. Это рабочая нагрузка того сервиса. Если хочется просто мерятся то есть бенчмарки от MySQL/MariaDB где они до 1кк держат на своих тестах

Интересно, спасибо.  Бенчмарки это не очень интересно, истории из реальной жизни всегда предпочтительнее )  В процедуре только чтение?

Разные есть, в той что под нагрузкой есть, но там UNLOGGED.

Это другой сервис, локальная машина и он в docker за его "сетью", запрос по HTTP: авторизация/проверка прав + отдача текущего юзера, СУБД CockroachDB, это просто для понимания

siege -b -t10s -H   'Authorization: Bearer d1be00a8-eb85-42bf-85a0-7d14e7c723e3' http://172.28.0.6:8000/v1/users/me
** SIEGE 4.0.4
** Preparing 25 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions:            7556 hits
Availability:          100.00 %
Elapsed time:            9.28 secs
Data transferred:          3.00 MB
Response time:            0.03 secs
Transaction rate:        814.22 trans/sec
Throughput:            0.32 MB/sec
Concurrency:           24.82
Successful transactions:        7556
Failed transactions:             0
Longest transaction:          0.14
Shortest transaction:          0.00

CPU

cat /proc/cpuinfo 
processor  : 0
vendor_id  : GenuineIntel
cpu family  : 6
model    : 60
model name  : Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
stepping  : 3
microcode  : 0x27
cpu MHz    : 3550.734
cache size  : 6144 KB

siege -b -t10s -H   'Authorization: Bearer d1be00a8-eb85-42bf-85a0-7d14e7c723e3' http://172.28.0.6:8000/v1/users/me
** SIEGE 4.0.4
** Preparing 25 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions:            7556 hits
Availability:          100.00 %
Elapsed time:            9.28 secs
Data transferred:          3.00 MB
Response time:            0.03 secs
Transaction rate:        814.22 trans/sec
Throughput:            0.32 MB/sec
Concurrency:           24.82
Successful transactions:        7556
Failed transactions:             0
Longest transaction:          0.14
Shortest transaction:          0.00

cat /proc/cpuinfo 
processor  : 0
vendor_id  : GenuineIntel
cpu family  : 6
model    : 60
model name  : Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
stepping  : 3
microcode  : 0x27
cpu MHz    : 3550.734
cache size  : 6144 KB

Ну, 814.22 trans/sec и 80к trans/sec - это как бы разница в 100 раз.  Про 1К RPS это понятно что будет работать.

но это ж чтение, да?

Это разные СУБД, разное железо и разные профили, тут не запрос к СУБД, а к сервису с его запросами (не одним) и его же оверхедом

Писать можно больше (в строках), но для реляционной СУБД это странно, если проще то они про почитать больше. Хотите писать много - юзайте заточенные под это СУБД