Асинхронность в DBD::Pg

[Rebus]

Очень любопытно. Я раньше слышал про эту фичу, но как-то руки и глаза не доходили документацию прочитать. Кажется, я уже даже знаю, где это можно применить, так что, спасибо.

[vodka_ru]

Главное с умом применять асинхронность. Иногда её применяют совсем не к месту. Статья понравилась, только все же код лучше подсвечивать.

[VaMpir]

Да, интересно.
А не знаете, есть ли что-то похожее для PHP?

[vodka_ru]

Я не встречал. Но я думаю, что в механизма наверно лежит работа с pipes.

[gugu]

нет :-) скорее с асинхронными сокетами

[hell]

Есть. pg_send_query и другие функции для асинхронных запросов. Правда, глубинное понимание того, как они работают, приходит, скорее, не после чтения мануала, но на собственном опыте. Впрочем, иногда оно того стоит

[gugu]

дружит. Единственное что — после отмены выполнения запроса транзакция ломается. Советуют выполнить ROLLBACK.

[youlose]

при чём тут это?

есть конечно? POE, например.
только тут о других вещах говорит автор топика

[youlose]

ну это другой подход опять же… тут объясняется про схему:

отправили запрос
делаем какие либо действия не трубующие результата этого (или этих если им много) запроса
когда понадобился результат: получаем ответ
обрабатываем ответ

Результат тот же, только многим людям понятнее чем callback'и
(Я не против callback'ов! В javascript их очень неплохо реализую и люблю использовать, программа симпатичней и логичнее получается, но это не для всех)
Просто тут другая парадигма.

[youlose]

кстати, опять же, используя threads.pm можно легко воплотить callback функционал

[youlose]

async callback функционал,
правда ниже 528depp написал оптимальное решение

[528depp]

В первую очередь стоит обратить внимание на AnyEvent::DBI. Правильно было написано выше что смысл асинхронности в вызове коллбэка, а не проверок в стиле «Ну что готово?» "-Нет" «Так, а сейчас может быть готово?».

[gugu]

AnyEvent::DBI создаёт ещё один поток. По своему опыту могу сказать — в Perl с потоками лучше не работать, если не хотите искать, почему ваша программа умерла с segmentation fault…

[528depp]

Насчет потоков — согласен, только AnyEvent::DBI создает не поток, а процесс, тоесть fork'ается.

[gugu]

ага. Создавать по процессу на соединение тоже не очень:
The overhead for very simple statements («select 0») is somewhere around 120% to 200% (dual/single core CPU) compared to an explicit prepare_cached/execute/fetchrow_arrayref/finish combination.
Вся проблема в том, что DBI не умеет работать асинхронно. Иногда можно забить на DBI и опустить на уровень DBD::Pg

[528depp]

Секунду, а причем тут процесс на соединение? Что вам мешает использовать один и тот же $dbh? Я понимаю что это решение не подойдет для web, но автор топика (вы) и не говорил про то что это конкретная заточка под web, как я понимаю речь идет об общем асинхронном программировании баз данных в Perl.
У меня много скриптов демонов висит которые используют именно AnyEvent::DBI.
Overhead в 120-200% я считаю очень даже допустимым, тока что набросал bechmark, 10к запросов «select 1», результат:
DBI (with explicit prepare): 0.688
DBI (with prepare in loop): 1.180
AnyEvent::DBI: 2.785
Возможно иногда и можно забить. Иногда нельзя, зависит от ситуации.

[ksurent]

Ну кстати под линуксом у меня вроде стабильно работали (без shared данных). Только вот расход памяти большой.

[youlose]

запускай потоки не от main пакета, будут маленькие, т.е. создавай отдельный package для запуска потоков

[ksurent]

Попробую, спасибо. Хотя, мне не кажеся, что это поможет.
В потоке запускается целый интерпретатор. Даже если делать отдельный пакадж, удаляя тем самым все локальные данные из контекста, все равно многовато получится. Тем не менее попробую померить.

[Suor]

стоит посмотреть также AnyEvent::DBD::Pg

[gugu]

Да, AnyEvent::DBD::Pg был написан буквально месяц назад, использует эту фичу и лучше всего подходит для этой задачи.