Performance degrades with larger result sets.

[abmusse]

Original report by Kristopher Baehr (Bitbucket: krisbaehr, GitHub: krisbaehr).

---

Whether running SQL statements, or SP calls, performance degrades significantly with this connector as the number of rows being returned increases. We have a stored procedure that returns a user-specified number of rows. When calling the same Stored Procedure with Node.js and JDBC on Tomcat, 100 rows or fewer results in Node.js is faster. But, when calling with 1000 rows, Node.js response times were averaging 650 ms, and JDBC on Tomcat average 250 ms. Nearly all time for these https requests is spent on the stmt.execute() and stmt.fetchAll() for the stored procedure call. The performance monitor indicated very similar response times from the SQL engine between these two methods. This indicates that something may need to be tweaked in the connector, or perhaps there is a connection or statement attribute that I need to set. Please advise.

[abmusse]

Original comment by Kristopher Baehr (Bitbucket: krisbaehr, GitHub: krisbaehr).

---

Upgrading to blocker. We cannot use Node.js on the IBM i for production purposes until this is resolved.

[abmusse]

Original comment by Kristopher Baehr (Bitbucket: krisbaehr, GitHub: krisbaehr).

---

I've been performance testing to get some more concrete numbers and from what I'm seeing this connector is not the issue. This issue can be closed.

[abmusse]

Original comment by Kristopher Baehr (Bitbucket: krisbaehr, GitHub: krisbaehr).

---

Not an issue with the connector.