I am looking to do some work around mysql and node.js and have found a few different modules out there but I cannot get a good bead on their stability/maturity. I know each author puts very hard work into each one, but for the work we're doing I need to know I've got a solid mysql foundation. The modules I've found that look pretty good are:
db-mysql This appears pretty active.
node-mysql This is a pretty pervasive module I've seen so far, it appears to be in a maintenance phase, and seems solid.
node-mysql-native I like the async work being done here, but I'm not sure how well it works yet.
node-mysql-libmysqlclient I'm not sure about this one, but it appears to be active as well.
I don't have many needs that are too far out of the ordinary. I need regular query support, extras would be nice, I just need a good foundation to start from. Any input as to the strengths and weaknesses of these modules would be great. If there is another quality contender I have not found I am not at all against considering another option.
I'm the author of node-mysql-native driver, from my point of view the differences are
no prepared statements support (yet) in node-mysql
according to my benchmarks node-mysql is 10-20% slower than node-mysql-native
node-mysql has much wider adoption, more tests and users. If you need stability, better use it
node-mysql-libmysqlclient is 2 to 3 times faster on fast queries. However, if you have a lot of slow queries and use connection pools it could be even slower than native JS driver because libmysqlclient async calls are based on nodejs thread pool and not on event loop.
update
As of 11/07/2013
(2). no longer valid (mysql-native is a bit slower than node-mysql)
have this alternative to node-mysql, on some benchmarks it's 2-3 times faster, has same API + support for prepared statements, SSL and compression. Also implements simple subset of server side protocol - see for example MySQL -> Postgres proxy.
node-mariasql is also a very good option (if it's ok to use binary addon) - fast, stable, async, prepared statements support, compression and SSL.
I went through a similar search and ended up settling on node-mysql. I like it's simplicity, the fact that it's pure js, and that it's well supported. It was slower in tests that I did than some of the mixed modules (those that used non-js libs), but I did a minor patch that helped considerably with that for my cases:
https://github.com/geochap/node-mysql
Related
since Apache released the first final version of Johnzon, it would be really interesting to see if there are already some comparison between Johnzon and FastXML Jackson to see if it is worth to switch. The most important topic is probably the performance.
Has anyone already done performance tests? Can you share your result?
Best
There are some performance benchmarks up on github.
But for each of them you really have to verify if the benchmark is actually correctly implemented.
For what I've seen most benchmarks use the official javax.* APIs in a sub-optimal way. Most use Json.createGenerator, etc but they should actually use JsonProvider.provider() and store this away for your operations. Then call createGenerator etc on this JsonProvider.
That way you can make sure that you really get comparable results.
We have done quite a few tests and for me the numbers of Johnzon look really good. And especially since it's much smaller than most other JSON libs.
As mentioned in several other sources and mailing lists(TomEE, for example), the performance gain, if any, is negligible especially when you compare it to the overall request-response processing chain.
If you use Spring Boot, you will find a lot more community support and flexibility in terms of features for Jackson.
Jackson has tons of different modules and good support for other JVM languages(for example KotlinModule).
We, in my project, also use quite a lot of Clojure, where we use Cheshire, which relies on Jackson under the hood.
In the end, it's up to you what to use and whether the cases I mentioned are applicable to your project, but so far I haven't seen any compelling performance reports about Johnson and until it happens, I would go for a library with a lot higher adoption in the industry.
We are starting a project that uses PyPy 2.2.1 and we want to start using SQLAlchemy in it. One thing we noticed is that when installing SQLAlchemy in the pypy virtual environment the following message appeared:
WARNING: C extensions are not supported on this Python platform, speedups are not enabled.
We, of course are concerned by the performance of the SQL queries that we will build and the manipulation of the result sets; and we don't really know how high can be the magnitude of these speedups not being enabled in SQLAlchemy. In addition, while we were looking into other solutions, for the sake of a test, installing Storm and SQLObject didn't throw any warning message like SQLAlchemy did in the pypy virtual environment.
In this specific scenario, would you recomend to still use SQLAlchemy even if the speedups are not enabled? or using an ORM like Storm would have better performance specially when dealing with complex queries and larger result sets?
the C Extensions in sqlalchemy provide a faster result set object than can be easily achieved in pure python, but you may get good benefits in this case from the pypy jit. Even if you don't, this won't in any way affect query performance. The warning can be safely ignored.
I've read this post about how inherently unsafe ruby's timeout method is, but I it looks like JRuby has natively implemented the Timeout class and I was wondering if those issues are still relevant in JRuby 1.7? From what I can decipher from the source, it looks like there is a reusable thread pool being used so that should take out a lot of the performance issues of launching a new thread for every single use, but I was wondering about the safety issues, specifically for when its being used extensively in Net::HTTP. Is there some kind of mutex locking going on to solve those safety problems now? (sorry i don't know java well enough to tell definitively from the source).
Long question short: is Timeout::timeout, and by extention Net::HTTP which uses it a ton, safe and performant to use in JRuby 1.7?
Yup, still unsafe in general:
No timeout library can solve this problem unless they are able to guarantee they'll never fire within any ensure blocks
Although, when used in Net::HTTP around pieces of code that don't have any ensure blocks, it should probably be fine I'm guessing. (Though they should really be using nonblocking io and select)
I read here that using the old mysql-functions is not recommended anymore. But is it of any use to make the effort to update the code in an already finshed and running project so only mysqli-functionality is used?
What would be the benefits?
What security issues would be enhanced?
If you have you security all right in the current project, it wouldn't be enhanced then.
Though, it is extremely common habit of PHP users to confuse security measures, so, you have to double-check. Say, if you're using a home-brewed version of magic quotes, by escaping all input parameters - you're in danger.
You need to audit the security despite of changing drivers though.
And you can achieve them without moving to mysqli, though.
As of benefits - there are none, compared to all the pains of rewriting.
If you're still in the mood of rewriting, I have a suggestion:
Instead of just rewriting from one raw API to another, let me suggest you to adopt some database abstraction library, moving raw API calls from all of your code into one compact place.
It will not only make your code dramatically shorter, but also will help in the future, when someone will have a whim to deprecate mysqli in turn - you will have to rewrite your class' methods only, not all the code.
The primary benefits you would gain from upgrading to the PHP mysqli extension are definitively listed on that page:
The mysqli extension has a number of benefits, the key enhancements over the mysql extension being:
Object-oriented interface
Support for Prepared Statements
Support for Multiple Statements
Support for Transactions
Enhanced debugging capabilities
Embedded server support
Security enhancements would generally not be discussed on public forums due to the potential for malicious individuals to use those security concerns on older, unpatched servers. Suffice to say that there are always improvements in new code, especially a driver called the MySQL improved extension.
I'm trying to find a library to access a database from an OCaml program. After trying ocaml-sqlite, I'm not satisfied, since it's somewhat slow.
I've seen a MySQL module, but it doesn't seem to be maintained.
Have you checked the Caml Hump? It has links to plenty of database bindings.
Good, mature, bindings that I can recommend are PG'OCaml by Richard Jones and postgresql-ocaml by Markus Mottl. They are both targeted at Postgresql (which is a probably a better choice for you considering you're into Ocaml).
ocaml-mysql works without problems here - mysql api for connect/query/fetch doesn't change that much :)
It lacks prepared statements though, had to implement mysql_stmt_* wrappers myself.
I'm quite surprised that you find the ocaml-sqlite bindings slow. sqlite is fast on its own, and I believe the sqlite bindings are very well written. You should make sure you're using the up-to-date binding from Markus Mottl's page
If your database is PostgreSQL, I recommend ocaml-postgresql. (There is also ocaml-sql, which makes some SQL operations more convenient when using ocaml-postgresql.)
Since PG'OCaml heavily relies on the OCaml's compile-time type system, it is impossible to compose queries at runtime, which makes it, in my opinion, not useful in most real-world scenarios.