[ANN] node-mysql-libmysqlclient is now async

[Oleg "Sannis" Efimov]

I have written yet about node-mysql-libmysqlclient, connector for
MySQL written in C/C + +:
http://groups.google.com/group/nodejs/browse_thread/thread/a75ea32221256616/8d5d59682ca3927b

So, I'm pleased to introduce you to version 0.0.7, which supports
asynchronous execution of queries: http://github.com/Sannis/node-mysql-libmysqlclient/tree/v0.0.7

For running async queries I use libeio thread pool. Recent patches for
this version introduced by Surendra Singhi (http://github.com/
ssinghi), which I am grateful for the help.

Future plans:
* More tests, especially for asynchronous requests
* Update API documentation and write examples for all functions
* Writing the benchmark for all currently existing connector to MySQL
* Implementation of prepared statements

I've also started writing benchmarks for MySQL bindings, you can
follow the development at http://github.com/Sannis/node-mysql-bindings-benchmarks

P.S. This announce in Russian: http://habrahabr.ru/blogs/webdev/102167/

[Isaac Schlueter]

npm publish?

--i

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>

[Felix Geisendörfer]

Nice, ideally we'll end up with two good mysql implementations : ).

A few questions:
- Do you already have some benchmark results to share?
- Is your driver now async for everything (including connect), or just
querying?
- In your test-async.js, you are doing result.fetchAll(). Is that
actually sync, or why do you need to call that in addition to just the
query callback?

--fg

On Aug 20, 8:11 pm, "Oleg \"Sannis\" Efimov" <efimo...@gmail.com>
wrote:

> I have written yet about node-mysql-libmysqlclient, connector for

> MySQL written in C/C + +:http://groups.google.com/group/nodejs/browse_thread/thread/a75ea32221...

>
> So, I'm pleased to introduce you to version 0.0.7, which supports
> asynchronous execution of queries:http://github.com/Sannis/node-mysql-libmysqlclient/tree/v0.0.7
>
> For running async queries I use libeio thread pool. Recent patches for
> this version introduced by Surendra Singhi (http://github.com/
> ssinghi), which I am grateful for the help.
>
> Future plans:
> * More tests, especially for asynchronous requests
> * Update API documentation and write examples for all functions
> * Writing the benchmark for all currently existing connector to MySQL
> * Implementation of prepared statements
>
> I've also started writing benchmarks for MySQL bindings, you can

> follow the development athttp://github.com/Sannis/node-mysql-bindings-benchmarks

[Guillermo Rauch]

http://github.com/Sannis/node-mysql-libmysqlclient/blob/v0.0.7/tests/test-async.js#L34

I think `query` should be async, and the sync version should be the explicit one (`querySync`), in a similar fashion to how fs is architectured.

--
Guillermo Rauch
http://devthought.com

[Oleg "Sannis" Efimov]

On 20 авг, 22:18, Isaac Schlueter <i...@izs.me> wrote:
> npm publish?
>
> --i

Yep, I just did it. I hope I have correctly figured out in npm.
On this occasion, I would suggest the possibility of using npm not
only for the root user,
as well as be able to automatically publish a package version for all
tags in the repository.

On 20 авг, 22:39, Felix Geisendörfer <fe...@debuggable.com> wrote:
> Nice, ideally we'll end up with two good mysql implementations : ).
>
> A few questions:
> - Do you already have some benchmark results to share?
> - Is your driver now async for everything (including connect), or just
> querying?
> - In your test-async.js, you are doing result.fetchAll(). Is that
> actually sync, or why do you need to call that in addition to just the
> query callback?
>
> --fg

You have done a great job over the node-mysql, I can not mention(I
cann't find a more appropriate word :-( ) it.
Yes, I can share my results on workstation(openSUSE 11.3, g++ 4.5.0,
node v0.2.0, mysqld 5.1.46):
Benchmarking Sannis-node-mysql-libmysqlclient:
**** Benchmark initialization time is 0.062s
**** 100000 escapes in 0.219s (456621/s)
**** 1000 sync reconnects in 0.243s (4115/s)
**** 10000 async insertions in 1.189s (8410/s)
**** 10000 rows sync selected in 0.07s (142857/s)
** Total time is 1.787s
Benchmarking felixge-node-mysql:
**** Benchmark initialization time is 0.101s
**** 100000 escapes in 0.198s (505051/s)
**** 1000 async reconnects in 1.003s (997/s)
**** 10000 async insertions in 1.962s (5097/s)
**** 10000 rows async selected in 1.365s (7326/s)
** Total time is 4.631s
Benchmarking stevebest-node-mysql:
**** Benchmark initialization time is 0.093s
**** 100000 escapes in 0.209s (478469/s)
**** 1000 async reconnects in 1.609s (622/s)
**** 10000 async insertions in 3.624s (2759/s)
**** 10000 rows async selected in 3.837s (2606/s)
** Total time is 9.373s
Your module without a doubt faster than the development of Yuichiro
MASUI and Stepan Stolyarov.
I understand that choosing the number of different benchmarks can be
achieved
first place in performance for both node-mysql-libmysqlclient and for
your node-mysql.
Main difference is for selecting and i think, that pure C
implementation of parser and access to V8 objects is expectedly
faster.
I admit that I could make a mistake in the benchmark and propose
overlook its code to avoid misunderstanding.

On 21 авг, 00:24, Guillermo Rauch <rau...@gmail.com> wrote:
> http://github.com/Sannis/node-mysql-libmysqlclient/blob/v0.0.7/tests/...
> I think `*query`* should be async, and the sync version should be the
> explicit one (`*querySync`*), in a similar fashion to how *fs* is
> architectured.
>
> --
> Guillermo Rauch

For you and last Felix question:
At this moment only query sending is async, fetch* functions are sync.
I received a few comments about the methods naming,
and soon all synchronous functions will be adopted by the 'Sync'
suffix. But I do not really understand how to deal
with the connected() method, which I would have left synchronous. I
plan to make asynchronous implementation connect() and fetch*()
by early September, when they are needed for my application.

I think to release an interim version 0.0.8, and for 0.1.0 implement
full asynchrony and freeze the API.
More will be only prepared statements, but I would not propose so far.

[Isaac Schlueter]

On Fri, Aug 20, 2010 at 16:03, Oleg "Sannis" Efimov <efim...@gmail.com> wrote:
> Yep, I just did it. I hope I have correctly figured out in npm.

Awesome. Looks good.

> On this occasion, I would suggest the possibility of using npm not
> only for the root user,

I don't run npm as root, or recommend doing so. In fact,

http://foohack.com/2010/08/intro-to-npm/#what_no_sudo

> as well as be able to automatically publish a package version for all
> tags in the repository.

The only tag that matters these days is "latest" which is
automatically attached to every publish. No need to tag anything. I
probably won't remove the feature, since it's simple and might turn
out to be useful, but no one uses it atm. It can be safely ignored.

Having both an interface to libmysql and a pure-js version is pretty awesome.

--i

[Oleg "Sannis" Efimov]

Thanks for your explanation :-)

On 21 авг, 03:47, Isaac Schlueter <i...@izs.me> wrote:

[Felix Geisendörfer]

> But I do not really understand how to deal
> with the connected() method, which I would have left synchronous.

If your connected method just checks the state of the socket (no I/O),
it's fine to leave it sync. If it sends a mysql ping command, it
should probably be async.

Regarding the benchmarks: This doesn't look too bad : )! I haven't
done any performance optimizations so far, but I hope node-mysql can
become more competitive on the SELECT performance.

--fg

On Aug 21, 1:03 am, "Oleg \"Sannis\" Efimov" <efimo...@gmail.com>
wrote:

[Oleg "Sannis" Efimov]

Hopefully I will not bore you with my announcements, but it's worth
it, because from now node-mysql-libmysqlclient is a stable module. All
functions tested for bugs and memory leaks when used in accordance
with examples [1]. Crash occurred in function fetchAll() has been
fixed. Also I've added API documentation [2].

Full changelog from v0.0.10 to v1.0.0:
* Fixes:
* Rewrite fetchAll function, move V8 stuff to EIO_After_FetchAll,
closes #34
* Rewrite MysqlResult::SetFieldValue() procedure to
GetFieldValue() function
* Fix Nodules break, closes #46
* Return Boolean/throw exception fixes, closes #31
* Allocate less memory in MysqlConnection::EscapeSync()
* Add useful macroses to simplify MysqlConnection and MysqlResult
* Fix lint errors
* Tests improvements:
* Refactor tests: split them into simple, complex, slow and
ignored
* Change nodeunit to original caolan's repo
* Add REPL memory leaks finder
* Documentation improvements:
* Add index.html generation from README.markdown
* Format ChangeLog with markdown
* Add changelog.html generation from CHANGELOG.markdown
* Add navigation
* Add zip- and tarball URLs to index.html
* Remove docs HTML from repo, you can generate them by 'node-waf
doc'
* Semantic versioning introduced
* Other changes in README and package.json

[1]: http://sannis.github.com/node-mysql-libmysqlclient/examples.html
[2]: http://sannis.github.com/node-mysql-libmysqlclient/api.html