Для нас основная не MS субд — mysql, больше реданденси мы добиваемся на multi-master percona
да это медленее при вставках, да это рассинхрон транзакций
но это реданденси и маштабированость
php-fpm расходует меньше памяти и работает быстрее на тяжелых php страницах вроде
overview.php, да большую часть задержки будет на работу БД, но генерация страницы это огромная работа
Например, наш overview для всех хостов и данных, создает html страницу объемом 50МБ!
Ее генерация требует более 1ГБ памяти и на mod_php это генерируется в 2 раза медленее
Это вполне конкретные цифры, речь не идет о коне в вакуме
Это multi-master
Сеть не является узким местом в таких системах, зато чтение происходит с разных нод перконы и чем их больше тем быстрее чтение, запись медленнее чем в одиночном варианте mysql но есть failover
по сути, это raid1 мира баз данных
Мы замеряли производительность подобных решений, кроме того, подобное решение обслуживает все наши web фермы
вот результаты тестирования производительности кластера в режиме записи и чтения в multi-master через haproxy
Running the test with following options:
Number of threads: 1000
Random number generator seed is 0 and will be ignored
Threads started!
OLTP test statistics:
queries performed:
read: 1400140
write: 400040
other: 200020
total: 2000200
transactions: 100010 (614.25 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 1800180 (11056.55 per sec.)
other operations: 200020 (1228.51 per sec.)
General statistics:
total time: 162.8157s
total number of events: 100010
total time taken by event execution: 162356.5746s
response time:
min: 45.35ms
avg: 1623.40ms
max: 6853.35ms
approx. 95 percentile: 2490.94ms
Threads fairness:
events (avg/stddev): 100.0100/1.02
execution time (avg/stddev): 162.3566/0.65
Для поддержания кворума, у нас есть несколько арбитраторов garbd
haproxy для балансировки запросов на percona,
percona для масштабирования и отказоустойчивости,
nginx отсанется на месте…
вообще вот статья про haproxy habrahabr.ru/post/198448/
я поддерживаю идею что php-fpm быстрее
сравнивал в реальных условиях сам, при работе с zabbix и для хостинга сайтов
по ссылке я читал, меня hello world на php не убедил
да это медленее при вставках, да это рассинхрон транзакций
но это реданденси и маштабированость
overview.php, да большую часть задержки будет на работу БД, но генерация страницы это огромная работа
Например, наш overview для всех хостов и данных, создает html страницу объемом 50МБ!
Ее генерация требует более 1ГБ памяти и на mod_php это генерируется в 2 раза медленее
Это вполне конкретные цифры, речь не идет о коне в вакуме
Сеть не является узким местом в таких системах, зато чтение происходит с разных нод перконы и чем их больше тем быстрее чтение, запись медленнее чем в одиночном варианте mysql но есть failover
по сути, это raid1 мира баз данных
вот результаты тестирования производительности кластера в режиме записи и чтения в multi-master через haproxy
[root@rs-haproxy ~]# sysbench --num-threads=1000 --max-requests=100000
--test=/usr/share/doc/sysbench/tests/db/oltp.lua
--mysql-table-engine=innodb --db-driver=mysql --mysql-db=test
--oltp-table-size=2000000 --oltp-test-mode=complex --mysql-engine-trx=yes
--oltp-auto-inc=off --mysql-user=tester --mysql-password=tester
--mysql-host='10.100.100.245' run
sysbench 0.5: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1000
Random number generator seed is 0 and will be ignored
Threads started!
OLTP test statistics:
queries performed:
read: 1400140
write: 400040
other: 200020
total: 2000200
transactions: 100010 (614.25 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 1800180 (11056.55 per sec.)
other operations: 200020 (1228.51 per sec.)
General statistics:
total time: 162.8157s
total number of events: 100010
total time taken by event execution: 162356.5746s
response time:
min: 45.35ms
avg: 1623.40ms
max: 6853.35ms
approx. 95 percentile: 2490.94ms
Threads fairness:
events (avg/stddev): 100.0100/1.02
execution time (avg/stddev): 162.3566/0.65
Для поддержания кворума, у нас есть несколько арбитраторов garbd
percona для масштабирования и отказоустойчивости,
nginx отсанется на месте…
вообще вот статья про haproxy habrahabr.ru/post/198448/