Pull to refresh

Comments 36

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


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

Пока ещё есть сомнения, что текущая реализация обёртки с мьютексами для запуска асинхронных запросов лучше, чем диспетчер с очередью запросов. Как только буду в этом уверен, будет v0.1.0 с зафиксированным API.
Таки можно оставить обе функции, а в первой сделать проверку параметра, и если он есть, то переход на вторую. Мне так кажется удобным, но решать в итоге, конечно, вам :)
Буду думать об этом :)
Я за переименование… Всё блокрующее в Ноде стоит помечать окончанием Sync а не наоборот…
Можно считать это уже решённым.
Да, или такой вариант. Потому что меня смущало именно то что использоваться обычно будет функция с более длинным именем.
Правда тогда остаётся открытым вопрос именования остальных функций. Большинство утилитарных функций предполагается использовать при инициализации приложения и у меня нет планов делать их асинхронными. Например такие функции как conn.setCharset(), conn.setSsl() и т.д. Мне кажется не стоит всем им приписывать Sync, если асинхронная версия не предполагается. Кроме того, для result.fetchAll() собираюсь сделать асинхронную версию, а вот для остальных fetch* собираюсь оставить синхронными для тех, кто переходит на Node.JS с PHP/Perl.
Стоит человеку переходящему с PHP/Perl не понимая того заюзать блокирующую функцию вне инициализации, как его проект начнёт дико медленно работать, и он будет во всю ругаться и кричать что Нода медленная, поэтому мне кажется Важно чётка Дать разработчику понять, что блокирует выполнение, а что нет.
Правильный аргумент. Чувствую грядёт массивная перетряска API.
Как же тогда существует в самой ноде такая вещь как fs.Stats? Я допуская правильность использования имён querySync, connectSync, но isConnectedSync (сейчас connected()) как-то не смотрится. Разве что делать её свойством, тогда оно будет использоваться только синхронно и вопрос именования снимается.
Однозначно требуется стандартное именование, когда синхронная версия имеет суффикс Sync, а все коллбэки имеют параметр err.
Присоединяюсь, уже на автомате почуял неладно и перечитал код в топике и понял такое.
UFO just landed and posted this here
Обновил пример: 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. Что касается биндингов, то тут тестов по этой части мало.
Спасибо за замечание, в следующей версии обязательно расширю документацию, давно её не дописывал.
Первый тест который я написал — это простейший http-сервер и http-клиент. Клиент DOS-ил сервер запросами. На ноуте (старенький MacBook Pro) серверный скрипт откушал 43Мб, а клиентский 6Мб. Серверный кушал порядка 65% процессора, а клиентский порядка 35%. netstat показал 16390 сокетов на порту, на котором велись тесты. Тест выдал порядка 6000 запросов в сек. Я считаю, что это очень неплохой результат.
11-12 000 одновременно подключенных держит.
А можете подробнее написать, каким образом реализована асинхронность?
+1. Очень интересно, как это удалось сделать.

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

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

Простите за мысли вслух. Просто у самого есть сейчас похожая задача, только для Perl'а. И пока еще не решил, что в итоге использовать: то ли Coro::Mysql попробовать, то ли DBSlayer (с ним, правда, тоже есть определенные неудобства, например то, что его придется поднимать для каждой базы отдельно. И если база, например, шардированная, то для каждого шарда отдельно. Это не очень удобно в эксплуатации), то ли свою http-прослойку наподобие DBSlayer'а написать.
Спасибо, разве что в DEscriptION обновить :-)
Я обычно статьи по Node.JSкладу в Web-разработку. Просто потому, что к традиционной тематике блога Javascript серверсайд имеет мало отношения.
Ого, спасибо.
Только не хватает инструкций о том, как это собирать. Просто на gcc или cpp скомпилировать?
$ node-waf configure build
в папке проекта. В README это есть, насколько я помню ;-)
Sign up to leave a comment.

Articles