Все равно не могу вдуплиться насчет i/o. То, что самые быстрые диски всё равно самое узкое место - это известно, но сейчас на серверах зачастую столько ram, что бывает можно установить такой заоблачный innodb_buffer_pool_size, что иногда и целая база может поместиться в ram. Чем больше буфер - тем меньше обращений к диску. В теории можно хоть всю бд поместить в ram, если она будет меньше допустимого innodb_buffer_pool_size.
А вот если например запустить много консьюмеров, которые будут что-то добавлять/изменять/удалять в одной таблице, вообще выполнять транзакции любые, то вырастет locktime, время ожидания освобождения блокировок, которое сам мускуль порождает. И сколько не профилировал запросы, i/o read/write конечно занимает время, но чаще всего меньше того locktime или самой выборки.
Или речь идет о том, что сами демоны обращаются к диску, что-то пишут на него или читают массово?
Очень интересная тема.
на счет lock time - а теперь представь что локи минимальны потому что у тебя все операции над данными изолированы, каждый в маленьком таком экторе, у каждого эктора маленький такой буфер сообщений, и каждый этот эктор делает что-то свое последовательно и все они работают в одном процессе (или даже в нескольких) деля процессорное время.
Проекты разные бывают. Если ты пилишь какой-нибудь твиттер/инстаграм/фэйсбук то ты не будешь в это упираться. Пилишь какую-нибудь систему документооборота где несколько человек могут одновременно работать с одним и тем же документом - тут нужны уже другие подходы что бы у всех все было хорошо. Или аукционы, видеоконференции какие и прочие вещи где "несколько человек одновременно работают с ресурсом" это обычное дело.
> И сколько не профилировал запросы, i/o read/write конечно занимает время, но чаще всего меньше того locktime или самой выборки.
с точки зрения твоего клиентского кода сделать запрос к БД это и есть операция ввода/вывода. Пока ты ждешь результат ты мог бы чего другого поделать, например разобрать запрос и понять для другого клиента чего выполнять и т.д.
> Или речь идет о том, что сами демоны обращаются к диску, что-то пишут на него или читают массово?
для php редко бывают задачи где диск медленный, ты как никак не пишешь каждый день какой-нибудь медиа сервер на пыхе. Все упирается в утилизацию процессорного времени. Если делать все синхронно и тебе там то в базу сходить надо то по сети куда-нибудь сходить то большую часть времени процесс с пыхом будет простаивать. А мог бы полезную работу делать.
> чтобы cli процесс уложил сервер целиком.
мне кажется что для тебя демоны/асинхронщина ограничиваются какими-то обработчиками сообщений из очереди или еще чего такое. Речь же идет о том что бы все приложение держать "не убивая", это добавляет пару вариантов как можно делать дела.
А если у тебя процесс обслуживает сотни клиентов, то случайный циклик заблочит работу для всех. Или скажем решил ты file_get_content заюзать какой (или что хуже - за тебя это решил автор библиотеки которую ты юзаешь для логов каких) и получаешь синхронную работу с файловой системой. Вроде не долго но тут чуть-чуть и там чуть-чуть и вот уже для всех клиентов время ожидания потихоньку увеличивается.
> Если с ним что-то не так, он вывалится по memory_limit рано или поздно...
или процесс свалится в своп. Оч занятное дело когда такое происходит.
> Или станет зомби процессом
процесс зомби звучит жутко но на самом деле это не так проблемно как процессы-сироты. В любом случае если у тебя там супервизор то странно откуда и тем и другим там взяться, разве что ты сам будешь плодить дочерние процессы.
