Are you sure this changes anything about performance?
The issue you're mentioning is because with ipv6 windows resolves localhost to ::1

I don't see why this should have an impact on the performance..
Resolving an ipv6 name to an ipv6 address definitely doesn't take 1-3 seconds.

Do you have any more background information about this?

for all people who host on windows machines and don't have access to a profiler tool or know how they work, you can easily measure this performance gain in google chrome developer tools (F12 in chrome), see the 'network' tab. After you changed localhost to 127.0.0.1, you will see a performance boots of almost 1 second in your first GET (the top row in the timeline)

again: this is mainly a windows hosting performance boost tip !

Yes , I monitored my php performance with XHPROF profiler (made by facebook, in their pre phphiphop days)...

with localhost as DB_SERVER the mysql_connect function always is the heaviest part of the total script execution with exclusive wall execution time over 1000000 microseconds

when changing localhost to 127.0.0.1 the exclusive execution wall time for mysql_connect falls back to 911 microseconds !!

Also have a look in google , keywords "php mysql_connect slow ipv6 windows"

or here :

http://www.bluetopazgames.com/uncategorized/php-mysql_connect-is-sl...

http://stackoverflow.com/questions/11663860/mysql-connect-localhost...

Interesting, thanks!

I had that problem a few times but always with the result that I wasn't able to connect to my MySQL server at all.

I've got quite a few Linux server and often profile things there, I certainly never had any connection time like that. My servers also support ipv6 and use "localhost" to connect to the MySQL database..

Hi, if you also do regular profiling, haven't you been surprised that C5 does do between 250-500 queries for an average page request?

And that often the heaviest queries in execution time are :
"SHOW COLUMNS FROM ....." which seems to come back in almost every page request

Well, surprised is the wrong word but I'm definitely aware of that!

The reason for this is often because of the "Page" object. This object is loaded for every page you show (in a page list or autonav easily 50 times or more). The page object load process is rather expensive because of the attributes as well. Every object usually has several attributes which are loaded with sql queries again.

50 page objects
10 page attributes
550 sql queries

You can use a cache to avoid this but I realized that the default file cache can actually slow down concrete5.

There's been a discussion about this:
http://www.concrete5.org/community/forums/customizing_c5/better-per...

I was surprised, cause i don't use lists much and never autonav.

But on a average page with 1 or 2 global areas, 1 or 2 stacks and say 4-8 content blocks or image blocks, it ends up in +/- 400-600 queries (and sometimes even more)..... and those queries are taking the most of the whole execution time.....

I do agree and noticed myself that the default cache can slow the system.....

About SHOW COLUMNS FROM

This isn't an expensive call on my system. I see that query but it doesn't take much time.

There are a few places where this is used, in the page list block:
concrete/blocks/page_list/controller.php

In the block controller to fetch the fields available in the block's main table:
concrete/libraries/block_controller.php

And in the attribute key controller:
concrete/models/attribute/key.php

We might be able to cache the result of this as well. The table structure doesn't change very often..

funny in every page request i do on my machine, these are BY FAR the most expensive queries and they do run on most (if not all) page request....

SHOW COLUMNS FROM `btCoreStackDisplay`
SHOW COLUMNS FROM `btContentLocal`
SHOW COLUMNS FROM `btContentImage`
SHOW COLUMNS FROM `btNdPhpBlockContent`
SHOW COLUMNS FROM `FileSets`
SHOW COLUMNS FROM `btSlideshow`
SHOW COLUMNS FROM `btCoreStackDisplay`

etc

On my prod sites/systems it's always about Page::getByID which takes about 40ms per call without a cache.

SHOW COLUMNS is barely measurable..
MySQL 5.1.63-0+squeeze1 on prod boxes.

How much time does a SHOW COLUMNS query take on your machine?

Thanks! I'm trying this out and it does seem to be snappier.