fix: mysqli and sqlite3 close statements after processing the results #9
Conversation
| @@ -140,6 +140,7 @@ public function _pQuery($strQuery, $arrParams) | |||
| } | |||
|
|
|||
| $this->intAffectedRows = $objStatement->affected_rows; | |||
| $objStatement->close(); | |||
There was a problem hiding this comment.
können wir das denn einfach so machen, weil innerhalb dieser getPreparedStatement gibt es ja einen Cache und der würde dann u.U. ein Statement zurückgeben was geclosed ist? Sonst müssten wir am besten den ganzen Statement-Cache ausbauen oder leeren.
There was a problem hiding this comment.
Hmm. Ggf brauchen wir hier in der Tat eher ein reset(). Problem ist wohl, dass die STMTs auf DB Eben auch über den Thread hinweg offen bleiben und dann irgendwann von der DB weggeräumt werden
Investigate why the number of statements being closed (Com_stmt_close) is low relative to the number of statements being opened (i.e. prepared, Com_stmt_prepare), currently at 100.0 percent.
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'com_stmt%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Com_stmt_close | 0 |
| Com_stmt_execute | 13141816 |
| Com_stmt_fetch | 0 |
| Com_stmt_prepare | 575723 |
| Com_stmt_reprepare | 0 |
| Com_stmt_reset | 0 |
| Com_stmt_send_long_data | 0 |
+-------------------------+----------+
7 rows in set (0.00 sec)
There was a problem hiding this comment.
ok, ist das denn egtl. schlimm wenn der Server das macht? Ansonsten ist halt die Frage ob wir diesen ganzen Statement-Cache dann nicht ausbauen und das close hier immer ausführen. Man müsste mal herausfinden wie viele Statements aus dem Cache wirklich wiederverwendet werden und wie sich das so von der Performance auswirkt.
No description provided.