This is a very curious one, I've been benchmarking queries in MySQL for over a year and reusing prepared statements is so much faster than preparing them on the spot that it's not even funny.
In my initial benchmarks, it appeared to be 30% faster, but perhaps due to many factors, when I ran one on a micro VPS a route with a single query clocked in at 400 req/s as opposed to the one with three queries clocking in at 1.8k req/s.
There are things I can do to get the speeds on both up, although I'm curious how I'll implement that on Docker, but these issues can be absolutely crippling to MySQL performance, I'm not sure how the PHP ecosystem handles it, probably by disabling prepared statements, but that's only a partial win and absolutely ruins security.
Although, to be fair, it could be argued that many sites have so little traffic that they're never really going to stress MySQL really heavily, as-long as they keep their query usage reasonable (it's not unusual to see major forum software claiming to be the "fastest" firing off 40 queries per page, then wondering why they're so slow).
MySQL is apparently making changes which are supposed to alleviate these issues, but it remains to be seen when these changes will become ubiquitous. It would seem that in the near future at-least, it would be prudent to open prepared statements (ala Go's pools) and to reuse them in various different connections.
Another solution might be PgSQL, but it might not be too suitable on ecosystems like PHP which open huge numbers of connections, as PgSQL's connections apparently have a surprisingly high amount of overhead. For that, you might need to use something like Node.js or Go to get the most value out of it.
In my initial benchmarks, it appeared to be 30% faster, but perhaps due to many factors, when I ran one on a micro VPS a route with a single query clocked in at 400 req/s as opposed to the one with three queries clocking in at 1.8k req/s.
There are things I can do to get the speeds on both up, although I'm curious how I'll implement that on Docker, but these issues can be absolutely crippling to MySQL performance, I'm not sure how the PHP ecosystem handles it, probably by disabling prepared statements, but that's only a partial win and absolutely ruins security.
Although, to be fair, it could be argued that many sites have so little traffic that they're never really going to stress MySQL really heavily, as-long as they keep their query usage reasonable (it's not unusual to see major forum software claiming to be the "fastest" firing off 40 queries per page, then wondering why they're so slow).
MySQL is apparently making changes which are supposed to alleviate these issues, but it remains to be seen when these changes will become ubiquitous. It would seem that in the near future at-least, it would be prudent to open prepared statements (ala Go's pools) and to reuse them in various different connections.
Another solution might be PgSQL, but it might not be too suitable on ecosystems like PHP which open huge numbers of connections, as PgSQL's connections apparently have a surprisingly high amount of overhead. For that, you might need to use something like Node.js or Go to get the most value out of it.
