Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78118 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21698 invoked from network); 16 Oct 2014 15:47:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Oct 2014 15:47:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.169 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.216.169 mail-qc0-f169.google.com Received: from [209.85.216.169] ([209.85.216.169:48663] helo=mail-qc0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 61/76-11594-888EF345 for ; Thu, 16 Oct 2014 11:47:23 -0400 Received: by mail-qc0-f169.google.com with SMTP id o8so3020486qcw.14 for ; Thu, 16 Oct 2014 08:47:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rg49VD+FuGxUJKwsRXdw6Kt9O8zE7SiMSid4ZKTmw68=; b=ed5HudsvgjgBI4IF5MLyAK/jprffePh8OasiMS/W8FtE1sNqKnP+J6vOLQsjSObcuX 850O8NOMk321QGuBrdfozwJdCExLroKKfbZaVUz0ttv/qDvs5PINghSDB19e+Bidr1fs wLcGiRFdDAM1eXAfxkAcpqT/9OgL+yJPGWl2GoBxuErtTk2kIqCeumu0chPkmWaMaDEe TtvQUuvxogDloRzc++edtGVJ7+/nwM+BGCiKgfHffqaGxnDIcQcIGcnieH1TgNPe0cG0 Fil+nLFocbwYoZsdUl0kb8k8HNXOOl2ryebmkrDYPWDxCC02UkgGSQL4yZY91kvjhpgQ MJIw== X-Gm-Message-State: ALoCoQkpePW3CEYL9gKKtSmY4pwTG9n6wTGCjifhR7N2e/XfnMjrL8pPKJatUgIp/Zb6gLFz8cQr X-Received: by 10.229.212.202 with SMTP id gt10mr3517412qcb.0.1413474437791; Thu, 16 Oct 2014 08:47:17 -0700 (PDT) Received: from [192.168.200.14] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPSA id w8sm21722935qag.2.2014.10.16.08.47.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Oct 2014 08:47:16 -0700 (PDT) Message-ID: <543FE883.2070401@lerdorf.com> Date: Thu, 16 Oct 2014 08:47:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ferenc Kovacs , Anthony Ferrara CC: PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql From: rasmus@lerdorf.com (Rasmus Lerdorf) On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara > 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