Download & Extend
Issues

Page caching performance II - PDO connection takes a long time

Posted by Heine on February 17, 2011 at 8:17am
Project:Drupal core
Version:7.x-dev
Component:base system
Category:bug report
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

Split from #1064212-9: Page caching performance has regressed by 30-40%:

I do have date.timezone set - as such the call to drupal_get_user_timezone only takes about 100 µs.

For my system (Windows 7, IIS / PHP 5.3 (fastcgi autoscales) + wincache 2 with MySQL via 127.0.0.1, all dbs with INNODB) the largest discrepancy between D6 and D7 comes from the time it takes to open a db connection.

In d6 this takes about 10% of the cached page request time (of 19 ms), in d7 it takes a whopping 35% (of 37 ms).

Note, this is seperate from the IPv6 issue many people run it to. I'm specifically using an ipv4-address. Using localhost takes > 1 second to wait on the first timeout.

I haven't found much on the why though. For those on Unices: sockets cannot be used on Windows. I do not use named pipes.

Login or register to post comments

Comments

#1

Posted by catch on February 17, 2011 at 8:19am

Subscribing.

#2

Posted by Heine on February 17, 2011 at 8:30am

To clarify the

Note, this is seperate from the IPv6 issue many people run it to. I'm specifically using an ipv4-address. Using localhost takes > 1 second to wait on the first timeout.

When using 'localhost' vs. '127.0.0.1' as the database host, connecting to the database takes over 1 second, probably by having the system try an IPv6 connect, then falling back to IPv4. That's a separate issue I wanted to rule out in #1.

#3

Posted by Heine on February 17, 2011 at 8:32am

#5

Posted by Heine on February 17, 2011 at 12:50pm

From berdir

I think the connect is using the socket for me and you are going through the IP. That is probably quite a bit slower. Will try to do a test on a clean install (I have tons of contrib modules enabled on the one I did the test) and using 127.0.0.1 instead of localhost as the database host. Another resource I just found mentiones reverse-lookup on the mysql side: http://allurcode.com/2010/04/07/mysql-very-slow-without-a-reason/

#6

Posted by Heine on February 17, 2011 at 12:55pm

DING DING DING. We have a winner.

With skip-name-resolve the page cache performance is near-IDENTICAL to that of D6.

Connection strings:

$db_url = 'mysqli://drupal:drupal@127.0.0.1/core6';

and
$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'core7',
      'username' => 'drupal',
      'password' => 'drupal',
      'host' => '127.0.0.1',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);

I would have expected the same effect of the name resolve on D6 and 7.

#7

Posted by andypost on February 24, 2011 at 4:45pm

Great idea to change defaults for hostname in drupal setup from localhost to 127.0.0.1

#8

Posted by jbrown on February 24, 2011 at 10:26pm

I think on unix localhost means that mysql will use a unix socket instead of TCP/IP. This is much preferable. Windows is being stupid.

#9

Posted by Heine on February 24, 2011 at 10:48pm

jbrown, we already know about sockets (and named pipes for that matter).

Apparantly, PDO vs. mysqli leads to some new delay when name resolution is enabled and the db is accessed via tcp/ip.

If you have nothing of value to say, please refrain from commenting.

#10

Posted by jbrown on February 24, 2011 at 10:55pm

Sorry - I was trying to be of value.

It's important that the default is not changed from localhost to 127.0.0.1

Perhaps we can include some logic where localhost is converted to 127.0.0.1 by Drupal when on Windows?

#11

Posted by Heine on February 24, 2011 at 11:10pm

The delay relative to D6 happens when 127.0.0.1 is used.

nobody click here