Node.JS
Comments 36
0
У меня тут есть один пустой коллективный блог, возможно администрация ответит на мой e-mail по поводу переименования.
-5
var conn = mysql_libmysqlclient.createConnection(host, user, password, database);


секьюрно ли в коде JS хранить настройки базы данных?
+5
Да. Node.JS работает на серверной стороне, так что файлы скриптов не должны быть доступны из сети.
0
Может слить вместе две квери функции и определять асинхронность по наличию коллбэка в параметрах?
0
Скорее всего перейдём в следующей же версии к стандартному именованию, вместо query/queryAsync будет querySync/query. Мне пока кажется, что бывают случаи, когда коллбек не обязателен, а запрос можно выполнить асинхронно.

Пока ещё есть сомнения, что текущая реализация обёртки с мьютексами для запуска асинхронных запросов лучше, чем диспетчер с очередью запросов. Как только буду в этом уверен, будет v0.1.0 с зафиксированным API.
0
Таки можно оставить обе функции, а в первой сделать проверку параметра, и если он есть, то переход на вторую. Мне так кажется удобным, но решать в итоге, конечно, вам :)
0
Я за переименование… Всё блокрующее в Ноде стоит помечать окончанием Sync а не наоборот…
+1
Да, или такой вариант. Потому что меня смущало именно то что использоваться обычно будет функция с более длинным именем.
0
Правда тогда остаётся открытым вопрос именования остальных функций. Большинство утилитарных функций предполагается использовать при инициализации приложения и у меня нет планов делать их асинхронными. Например такие функции как conn.setCharset(), conn.setSsl() и т.д. Мне кажется не стоит всем им приписывать Sync, если асинхронная версия не предполагается. Кроме того, для result.fetchAll() собираюсь сделать асинхронную версию, а вот для остальных fetch* собираюсь оставить синхронными для тех, кто переходит на Node.JS с PHP/Perl.
0
Стоит человеку переходящему с PHP/Perl не понимая того заюзать блокирующую функцию вне инициализации, как его проект начнёт дико медленно работать, и он будет во всю ругаться и кричать что Нода медленная, поэтому мне кажется Важно чётка Дать разработчику понять, что блокирует выполнение, а что нет.
0
Правильный аргумент. Чувствую грядёт массивная перетряска API.
0
Как же тогда существует в самой ноде такая вещь как fs.Stats? Я допуская правильность использования имён querySync, connectSync, но isConnectedSync (сейчас connected()) как-то не смотрится. Разве что делать её свойством, тогда оно будет использоваться только синхронно и вопрос именования снимается.
+1
Однозначно требуется стандартное именование, когда синхронная версия имеет суффикс Sync, а все коллбэки имеют параметр err.
0
Присоединяюсь, уже на автомате почуял неладно и перечитал код в топике и понял такое.
UFO landed and left these words here
0
Обновил пример: gist.github.com/537870

Сам Node.js тестировали и много. Можно начать с записей разработчиков на этот счёт(http://four.livejournal.com/1018026.html, four.livejournal.com/1019177.html, four.livejournal.com/1020129.html, http://debuggable.com/posts/node_js:4ab4d9d7-b788-41d4-85c0-1b51cbdd56cb), за более поздними бенчмарками я не следил, но думаю качественно картина осталась такой же. Память течёт мало и всегда можно запустить GC. Что касается биндингов, то тут тестов по этой части мало.
0
Спасибо за замечание, в следующей версии обязательно расширю документацию, давно её не дописывал.
0
Первый тест который я написал — это простейший http-сервер и http-клиент. Клиент DOS-ил сервер запросами. На ноуте (старенький MacBook Pro) серверный скрипт откушал 43Мб, а клиентский 6Мб. Серверный кушал порядка 65% процессора, а клиентский порядка 35%. netstat показал 16390 сокетов на порту, на котором велись тесты. Тест выдал порядка 6000 запросов в сек. Я считаю, что это очень неплохой результат.
0
А можете подробнее написать, каким образом реализована асинхронность?
0
+1. Очень интересно, как это удалось сделать.

Автору — спасибо!
0
Добавил раздел «Реализация асинхронности» в пост. Запросы выполняются в потоках на основе libeio, включённого в Node.JS.
0
Спасибо за ответ. Понятно. Что-то вроде этого и ожидал.

Да, к сожалению это не очень подходящий вариант, если к нам одновременно приходит достаточно много запросов, в каждом из которых нужно сходить в базу. Можно, конечно, создать пул коннектов к базе, чтобы можно было параллельно задавать несколько запросов к базе. Тогда получится что-то похожее на DBSlayer, только через DBSlayer можно контролировать общее количество коннектов к базе, а тут каждая клиентская программа будет решать, сколько ей нужно коннектов.

Простите за мысли вслух. Просто у самого есть сейчас похожая задача, только для Perl'а. И пока еще не решил, что в итоге использовать: то ли Coro::Mysql попробовать, то ли DBSlayer (с ним, правда, тоже есть определенные неудобства, например то, что его придется поднимать для каждой базы отдельно. И если база, например, шардированная, то для каждого шарда отдельно. Это не очень удобно в эксплуатации), то ли свою http-прослойку наподобие DBSlayer'а написать.
+1
Я обычно статьи по Node.JSкладу в Web-разработку. Просто потому, что к традиционной тематике блога Javascript серверсайд имеет мало отношения.
0
Ого, спасибо.
Только не хватает инструкций о том, как это собирать. Просто на gcc или cpp скомпилировать?
0
$ node-waf configure build
в папке проекта. В README это есть, насколько я помню ;-)
Only those users with full accounts are able to leave comments., please.