Thread

Um, I’m not on a local server. I’m happy to give access but you never asked *sniffle…sniffle*

For that last template:
Elapsed Time: 11.9743
Total Queries: 26

The “anything unusual” from the template debugging:
(0.362045) -> Method Called: entries
(11.125859) -> Data Returned

Ah, my fault.  Your test installation I was assuming was local this whole time.  Well, send FTP and Super Admin access to me via email (not PM) please, post haste! :-D

After some laborious line-by-line time evaluation, I drilled deeply enough to find the problem.  To protect certain urls in pMcode, in the method that handles auto-linking in weblog entries, we generate a hash.  With your server’s settings, the effective code this runs is:

sha1(uniqid(mt_rand()));

uniqid() is taking 2/100ths of a second on this server, multiplied by each custom field, and again by each entry being displayed.  So it was adding between 8-13 seconds on page loads for 11 custom fields and 60 entries (.02 x 11 x 60)!  This can be made more efficient as we don’t need to generate a unique hash for each iteration of that method, so I have modified this on your server, and will be adding it to our development files as well.

It has something to do with the underlying libraries intentionally delaying execution of the thread so that calls for unique id’s occurring simultaneously become staggered effectively preventing identical id’s from being generated at the same time by the server.  But it’s only supposed to take a 1 millisecond breather, not 20. 

I’ve left a test file on your server (details in the email I sent you) that can help demonstrate this problem for your host, if they are inclined to look into it.  1000 iterations of uniqid() on this server takes 20 seconds.  By comparison, it takes 1/2 a second for the same on my server.  The second output message is also a call to uniqid(), but with an additional flag that uses a different method to try to guarantee uniqueness, that does not result in the thread being “put to sleep” temporarily.  You can see that it’s blazing fast by comparison.

Ok, I’m done techno-babbling.  It’s fixed for you, so make sure you hang onto that core.typography.php to use when you upgrade your live site.  And starting with the next released build, this fix will be included, so you won’t have to worry about it for the long haul.

Thank you so much for the assistance! I have 3 other sites to upgrade so I presume I should use the changed core.typography.php file for each?

So, to sum it up, it was a combination of a server thing and an EE thing? God, I hate when that happens. 😊

Yes - strictly speaking, it’s a server issue.  But it’s one that we have the ability to work around with a slight alteration of our code.

In the interim, Paul posted a build update. Is the fix in that typography file or should I stick with the one you made changes to on my server?

Yes, it’s been incorporated in this build.