On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara <ircmax...@gmail.com> > wrote: > >> Hello all, >> >> I raised this topic on list over a year ago ( >> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was >> determined that it wasn't time yet to disable prepared statement >> emulation for MySQL yet. However, Rasmus did mention that it was a >> possibility for 5.4 ( >> http://marc.info/?l=php-internals&m=130418875017027&w=2 ). Since that >> ship has sailed, I submitted a pull request for trunk to change the >> default value of prepared statement emulation for MySQL. >> >> https://github.com/php/php-src/pull/108 >> >> https://bugs.php.net/bug.php?id=54638 >> >> Does this need to be an RFC (should I draft one)? Or can it just be >> pulled as-is? >> >> Thanks, >> >> Anthony >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > hi, > > do we want to change the default for this in PHP7?
Honestly, I am not sure about this anymore. There is a significant performance benefit in doing client-side prepares. Last year I attempted to switch to server-side prepares on Etsy's production servers but it added 30-40ms of page latency because of the extra round trips. And yes, we were doing too many queries, but I fear if we change this default people won't understand where this slowdown is coming from. Of course, in some rare cases using server-side prepares might speed things up because of prepared statement caching in the server, but I have yet to see a case where that caching outweighs the extra tcp roundtrip overhead. I do agree that the default should probably be server-side since it is the least surprising. We just need to make it very very clear in the upgrade doc that this change will likely slow down peoples' apps and show them how to turn client-side prepares back on. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
