node and ibm_db getting slower with each node release #269
Comments
|
@amcintyre99 If without changing the code of ibm_db, it performs slower with different versions of node.js, means issue is with node.js itself. Also, you already verified with two drivers. So, please open issue with Node. It does not seem an ibm_db issue. Thanks. |
|
@bimalkjha Unless you or @amcintyre99 can point to specific reasons why it is slower, it is extremely unlikely that anyone at nodejs/node is going to look at it. (I'm saying this with my node.js maintainer hat on. Not many people have the time or inclination to sift through thousands of lines of third-party C++ code on the off chance that the issue is with node.js and not the third-party module.) |
|
Well, in that case https://gist.github.com/amcintyre99/4d13fbab65e78694accaf81ce95af6b9 should be updated to distinguish between the time consumed by node.js code and C++ code. Thanks. |
|
If someone would tell me how to "distinguish between the time consumed by node.js code and C++ code", I will be glad to rerun the timings. |
|
You can use perf(1) (see |
|
this was fun andrew@sherlock: i'm seeing strike through'ed lines above, not sure why |
|
also used the node profiler and got this here is the summary section followed by the first line of C++ section |
|
Your version of perf seems to be too old to understand the .map files that Nothing really stands out but I noticed that lib/odbc.js is sloppy mode code. Adding a By the way, is your nodejs binary from the ubuntu repos? Have you tried the official ones from https://nodejs.org/? I ask because some ticks are counted twice (once as C++, once as Shared libraries), which is a bug that doesn't exist in the official binaries as far as I'm aware. |
|
I should add that since the lion's share is node sleeping in a syscall, most of the work probably takes place off-thread, in odbc's thread pool. |
|
re perf, am very current, probably just didn't point to the .map files i will try 'use strict' nodejs binary installed via latest nodesource package |
|
with 'use strict' got this immediately i'm not much of a js coder so will need the package maintainers to try this change. thanks!! |
|
jeez, /proc/sys/kernel/kptr_restrict change required for perf has symbols now |
|
both with symbols, they are very different |
|
Can you try v6 with Suggests V8 spends quite a bit of time compiling JS code but it would be good to know the call graphs leading up to pthread_cond_wait().
perf is supposed to pick them up automatically from /tmp. Yours (4.4) I suspect is too old but it's easy to build from source: download recent kernel tarball, unpack and |
|
-g done, report file large so gzipped |
|
Thanks. That one shows node spending nearly all its time either in the write(2) system call or waiting on a mutex, which is quite different from the last one. I don't really have any suggestions to offer. |
|
here is same code 3 times without the -g, but all are different |
|
node profiler is consistent with run 2 days ago |
amcintyre99
changed the title
|
latest timings with ibm_db 2.1 |
|
@amcintyre99 Please share the latest timings with [email protected] . Thanks. |
|
latest timings |
amcintyre99
changed the title
|
870 better than 860 |
|
893 slightly faster than 870, probably just noise fyi, all of these timings were done on same box, best of 10 with performance gov set and nothing else running |
|
894 faster than 893 |
|
6x and 8x slower than 4x might be related to this open nodejs issue |
amcintyre99
changed the title
|
latest timings node and ibm_db getting slower with each node release |
|
fyi, here is the code i'm using "use strict";
var common = require("./commons")
, odbc = require("ibm_db")
, db = new odbc.Database()
, iterations = 100000
;
db.open(common.connectionString, function(err){
if (err) {
console.error(err);
process.exit(1);
}
issueQuery2(function () {
finish();
});
});
function issueQuery2(done) {
var count = 0
, time = new Date().getTime();
var stmt = db.prepareSync('select cast(? as integer) as test FROM SYSIBM.SYSDUMMY1');
for (var x = 0; x < iterations; x++) {
(function (x) {
stmt.executeNonQuery([x], cb);
})(x);
}
function cb (err, data) {
if (err) {
console.error(err);
return finish();
}
if (++count == iterations) {
var elapsed = new Date().getTime() - time;
console.log("%d queries issued in %d seconds, %d/sec : Prepare - ExecuteNonQuery ", count, elapsed/1000, Math.floor(count/(elapsed/1000)));
return done();
}
}
}
function finish() {
db.close(function () {
console.log("connection closed");
});
} |
|
Tested on Ubuntu LTS 14.04 against remote DB2 Server v11.5.1.0 using perfTest.js. [email protected] shows better performance using node.js v12.x compare to node.js v11.x [email protected]: [email protected]: |
|
Great improvement. Still not as good as Node V4 or V6 (see above) but 2.6.2 and V12 much better. Thanks!! |
|
@bimalkjha Any idea how it performs with Array as input. Also, what's the best way to update 100000 records. Using array promises? |
|
Vote up |
The subject says it all. And original odbc module has same issue.
timings
https://gist.github.com/amcintyre99/87ab958187f30989b816d238d341566d
code
https://gist.github.com/amcintyre99/4d13fbab65e78694accaf81ce95af6b9
db2 v11 on ubuntu 16.04 x64
any thoughts?
The text was updated successfully, but these errors were encountered: