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