Pooling соединений к базе данных на node.js

[domix32]

Неплохо было бы Balanser заменить-таки на Balancer, раз уж оно на гитхабе.

[stalehard]

Бес попутал. Исправил, спасибо.

[AndyGrom]

Раз уж исходники на GitHub`е, зачем Вы продублировали эти простыни на хабр, и даже под спойлер не убрали?

[stalehard]

Спасибо, убрал

[stalehard]

Если замечания конструктивны и верны, почему бы нет

[kaero]

А зачем в конструкторе Connect устанавливается обработчик события error, который бросает полученное исключение? Реализация EventEmitter в Node.js ведет себя так по-умолчанию, но учитывая домены, например.

Еще можно использовать EventEmitter, как прототип Connect, что добавит изящности, избавит от переопределения метода on() и позволит в обработчиках событий обращаться к экземпляру Connect через this, т.к. обработчики событий в EventEmitter выполняются в контексте экземпляра.

В методе addQuery лучше обернуть вызов _nextTick() в setImmediate, т.к. помимо добавления запроса в очередь будет сразу произведено и выполнение, что не очень хорошо с точки зрения «асинхронного» API. Аналогично я бы поступил с вызовом el.callback(null, result);, чтобы внутренний колбэк таки завершил свою работу (бросил событие drain), а затем уже был вызван пользовательский обработчик.

Ну, и глаз зацепился ;)

if(!(typeof query == 'string')) /* => if (typeof query !== 'string') */

[kaero]

И еще немного побрюзжу по поводу нейминга и реализации. То, что вы реализовали традиционно называется connection pool – пул соединений. На качественную реализацию пула соединений на node.js можно посмотреть в стандартной библиотеке node.js: http.Agent. Balancer можно реализовать, используя принципы, что применяются в Агенте:

• до лимита соединений создаем новые
• ставим обработчики событий соединения, которые приводят к освобождению соединения (ошибки, таймауты, успешные завершения)
• по достижении лимита ставим запросы в очередь в пуле
• при освобождении соединения проверяем очередь на наличие запросов: если есть — назначаем освобожденному соединению первый
• если соединение пришло в состояние, когда его нельзя переиспользовать (ошибка соединения), выбрасываем его из пула
• если соединение позволяет указать таймаут простоя (idle timeout) — используем его для удаления соединений из пула, так при отсутствии нагрузки пул постепенно освободится «сам»

[stalehard]

Дельные советы, спасибо за наводку на http.Agent — здесь этот принцип придется очень кстати.

[vitvad]

эх, от вас бы еще пару статей хороших по ноде и на плюс в карму уже было бы. Спасибо за дельные комментарии.

[miripiruni]

Как минимум есть вот это: tech.yandex.ru/events/yasubbotnik/spb-jun-2013/talks/937/

[Zalmoxis]

Чем не устраивает дефолтовое управление пулом коннектов библиотеки pg?

Предлагаю расширить вашу библиотеку. Я использовал бы для пула реквестов к разным внешним апи.

[kaero]

А что вы понимаете под «внешними API»?

Если вы про HTTP, то взгляните на asker — это обертка над http–клиентом Node.js, ориентированная на взаимодействие «сервер ↔︎ сервер». Среди отличительных особенностей как раз возможность использования разных пулов соединений для разных запросов. В комменте выше miripiruni привел ссылку на видео, где я чуть-чуть про нее рассказываю.

Если же мы говорим, про пулы TCP соединений, то стоит обратить внимание на модуль jackpot и клиент memcached в качестве примера использования.

[stalehard]

Да, каждый раз убеждаешься, что все уже придумано до тебя, а ты просто вновь изобретаешь велосипед. Но так и развивается профессионализм :)

[Zalmoxis]

Да, хотелось иметь пулл обращений к api vkontakte, facebook, google… Спасибо большое за наводку и за видео!

[stalehard]

Как раз была нужна унифицированная абстракция высокого уровня, чтобы манипулировать каналами. В ближайшее время реализую замечания, высказанные товарищем kaero , поскольку считаю их как никогда уместными. Затем подумаю, как наиболее просто интегрировать различные сервисы в него. Готов всем помочь. Пишите, отвечу.