Very long TTFB since last update

@xanathon: What PHP versions is your server running? Which WordPress version? Does it also happen with a previous version (4.1.x)? (I can’t really imagine a situation where a TTFB of 8 to 13 seconds won’t result in a request timeout, though.)

Addendum: The TTFB is certainly not normal, I just ran webpagetest.org on my blog and get a TTFB of < 1 second (with a whole bunch of plugins besides wp-Typography enabled).

• This reply was modified 7 years, 8 months ago by pepe.

Thanks for your quick reply.

The WP version is 4.8, PHP is 5.6.30-0+deb8u1 . The request timeout seems to occur at 15 seconds.

I just rolled back to 4.2.1 and everything is fine again with TTFB under one second.

• This reply was modified 7 years, 8 months ago by xanathon.
• This reply was modified 7 years, 8 months ago by xanathon.

Did you notice any output in the error log?

If you not, I can only think of one change that might have had such a dramatic effect on execution time. Could you please try to enable 4.2.2 with one function changed? Specifically, you’d need to replace the method Strings::mb_str_split in wp-typography/php-typography/class-strings.php with the version from 4.2.1 (just that one method).

I can do that later as I do not have the time to try that atm. For the time being I’m happy with version 4.2.1 working.

So there were no error messages in the log, @xanathon?

@xanathon: Have you had a chance to try the workaround yet?

Any news, @xanathon?

@xanathon: Did you see anything in the logs? I’ve tried comparing the two mb_str_split implementations in a synthetic test and arrived at these results:

Testing PHP 7.1.8:
1000 iterations took 26.465047836304 seconds (mb_str_split_421).
1000 iterations took 0.48836088180542 seconds (mb_str_split_422).

Testing PHP 5.6.31:
1000 iterations took 27.221343040466 seconds (mb_str_split_421).
1000 iterations took 1.2820391654968 seconds (mb_str_split_422).

It looks like the 4.2.2 implementation is faster even on PHP 5.6. Unfortunately, this means I’m not sure how to proceed debugging this without more input from your side.

@jerzyk has notified me of an apparent issue in 5.0.x which I now believe was switched on (not introduced) in version 4.2.2 related to caching. Details can be found in his thread. I’m releasing 5.0.3 to alleviate the issue. (A more thorough fix will appear in a later version).

I’d be interested in hearing if 5.0.3 reduces TTFB to normal levels in your installation, @xanathon.

Sorry for the late reply but I had no time to test the hotfix, after that I was on vacation and still after that I had heavy workload.

I just installed 5.0.4. and it looks fine at first glance. I will test further. Thank you for your help.

@xanathon: No problem, the supposed hotfix would not have worked anyway. I think it was the issue identified by @jerzyk, probably triggered only in some cases depending on database sizing and/or concurrent hits on uncached posts. Keep me updated if any further issues arise.

After some tests I had to reinstall 4.2.1. With 5.0.4 Google or Facebook were no longer able to fetch post images. After rollback to 4.2.1 it worked again.

@xanathon: Could you reproduce this on a test environment where I can look at the resulting HTML code? It sounds like a HTML parser issue and might be mitigated by disabling the “Ignore Parser errors” setting.

@xanathon: Any chance for me to see a non-working live page?