Hfnas, нет. вы спрашиваете как мне выдернуть защиту от детей из розетки и засунуть туда пальцы. я лишь пытаюсь вам обьяснить что вы уверены что хотите выйти в сеть именно таким образом? Может вместе получится найти так сказать менее членовредительский вариант?
Александр Панков, и вам кажется что стало понятнее?
У диска есть скорость на чтение/запись - в идеальной ситуации именно с такой скорость он может писать ваши кортежи на диск - скорость записи диска разделить на размер одного кортежа. Идеала вы конечно не получите никогда - особенно если у вас с этим же диском возится nginx, php и вагон всего. Но прикинуть можно.
Но дать точный ответ на ваш вопрос вам дать никто не сможет. Потому что вы играете в анекдот про сферического коня в вакууме. При наличии мозгов и хорошего знания инструментов которые вы собираетесь использовать - MySQL, Laravel, PHP, нормальной скорости api - можно писать в миллион раз больше записей, но как бы при всем уважении никто не может быть увереным в хорошем знании инструментов. Не говоря о том что что вы вообще делать будете на этом сервере - может там какие нибудь шизанутые расчеты, которые сожрут всю память, весь диск на своп, и мускул там будет курить в сторонке.
Александр Панков, ну и в чем проблемы тогда? Получили запрос от пользователя - создали Job отправили в очередь. Какой нибудь rabbitmq эти задачи будет жрать как не в себя. Другое дело что разбираться эти задачи будут со скоростью которую позволят ресурсы. Но ваш сервис всегда будет принимать задачи от пользователя
может ли MySQL писать 445 записей в секунду,
Вы же понимаете что это дурацкий вопрос, и дурацкая постановка? У вас в 1 записи может быть одна колонка со статусом true/false, а может быть 100 колонок с текстом, каждая из которых содержит Войну и Мир Льва Толстого.
Смотрят на обьемы записи/чтения на диск а не на количество попыток этих записей
вопрос нужны результаты сразу же. если нет - кладете в очередь и обрабатываете постепенно. при таком варианте вы можете принимать от пользователя можно хоть миллион задач на обработку.
если вариант человек дает задачу и сразу должен получить ответ - тут сложнее. сильное подозрение что сторонний апи вас пошлет нахрен быстрее чем вы упретесь в базу.
не мудрено. первый middleware проверяет - и дает отлуп, до второго дело даже не доходит.
написать свой - который будет проверять сначала одно, потом второе, потом уже давать отлуп
Дмитрий, короче. оставьте одного демона на обработку очереди. посмотрите деградирует ли вставка. если нет - смотрите что там с локами, и ожиданием и запросами, если у вас там не просто вставка, а какие нибудь проверки на наличие дубликатов.
Дмитрий, ну это может быть связано с тем что совпадает что у вас все демоны в одно и ту же милисекунду пытаются писать в таблицу, а у вас там какой нибудь уникальное поле, какие нибудь локи, и одна вставка ждет другую.
можно попробовать половить подобное через show profile или через slow log, оно вроде тоже локин тайм показывает.
Дмитрий, простите, чего то я не понял. у вас таки деградирует время записи? ну то есть с каждой задачей у вас тратится больше времени на вставку одной записи, или наоборот? По факту вы же можете к разнице времени которую пишете в лог добавить какую по счету запись текущий демон выполняет. А для того что бы легче было отлаживать сократить количество демонов на обработку - до одного.
