Comments 16
В случае синхронного выполнения запросов, Вы сможете получить результаты их выполнения через t1 + t2 + t3 (ex: 6 секунд), а в случае асинхронного выполнения запросов уже за max(t1, t2, t3) (ex: 3 секунды)
Конечно, т.к. в приведенном случае они (запросы) ничего не делают. А для реально выполняющихся запросов понадобится все 6 секунд плюс время на переключения потоков (в случае, если у нас одно ядро)…
Ох уж эта Ваша реальность:-)
Согласен с тем, что пример не реален, а идеален. Но считаю, что именно от этого надо плясать, поэтому и придумал именно такой пример. Насчет цифр — есть пример на гибхабе, туда вставляйте свой запрос и смотрите, для каждого цифры будут разные, например, у меня асинхронный вариант, все равно(но не всегда) выполняется немного быстрее
Согласен с тем, что пример не реален, а идеален. Но считаю, что именно от этого надо плясать, поэтому и придумал именно такой пример. Насчет цифр — есть пример на гибхабе, туда вставляйте свой запрос и смотрите, для каждого цифры будут разные, например, у меня асинхронный вариант, все равно(но не всегда) выполняется немного быстрее
Т.е я могу во время загрузки страницы кинуть AJAX-запрос и асинхронно сделать асинхронные запросы и всё будет супер быстро?
Как я понял, они буду выполняться одновременно, а не последовательно?
Как я понял, они буду выполняться одновременно, а не последовательно?
В целом такой вариант использования скорее анти-паттерн и использовать этот функционал таким образом — нехорошо, потому что надо дождаться результата выполнения запроса, а не оставлять его на произвол судьбы. Однако основная мысль именно такая: если в скрипте присутствует только выполнение запроса, то да, все будет очень быстро, но потом новый запрос в том же соединении не заработает(Commands out of sync) пока не будут получены результаты текущего, то есть надо будет сотворить что-то в стиле: выполнил запрос асинхронно, закрыл соединение. Остается вопрос: что будет если закрыть соединение у выполняющегося асинхронно апдейта например? Думаю, что ничего хорошего, а оставлять соединение открытым вообще плохо.
Если Вы про пример, то одновременно, так как разные соединения.
Если Вы про пример, то одновременно, так как разные соединения.
для этого не нужен mysqlnd
Рабочие примеры есть?
Учитывая то, что оно требует отдельное подключение к MySQL для каждого параллельно выполняющегося запроса вместо пайплайнинга, выглядит абсолютно бесполезно в 99% случаев.
Может пригодиться только если вы пишете на PHP демонов и держите пул подключений.
Может пригодиться только если вы пишете на PHP демонов и держите пул подключений.
Подключение к MySQL выполняется весьма быстро, порядка 1 мс, но для обычной веб-страницы это всё равно изврат, конечно :)).
Есть у вас импорт например… Построчный… Лучше же делать в 20 потоков чем в 1, не?
Это может отлично пригодится если в проекте используете шардирование данных на уровне бизнес-логики и возникает необходимость сделать 10 одинаковых запросов к 10 разным серверам.
А на примере PDO показать не лучше было? Или поддержка только в mysqli?
Sign up to leave a comment.
Асинхронные запросы к MySQL