• Resolved Richard Vencu

    (@rvencu)


    Hi. I tracked bad performance on my PHP app and ended up with a 3.6 seconds PHP execution time saving by disabling this plugin. The apply_styles for print_styles was taking a lot of time, over 3.5 seconds out of 7 seconds total for the page

    Is there possible to fix this issue? I was profiling the homepage from an admin account so wp rocket was not involved.

    after disabling this plugin the admin-ajax.php worst timing dropped from 27 sec to 15 sec.

Viewing 14 replies - 1 through 14 (of 14 total)
  • Plugin Author Derrick Hammer

    (@pcfreak30)

    Is object cache running?

    Thread Starter Richard Vencu

    (@rvencu)

    yes, redis with PHP extension installed

    Plugin Author Derrick Hammer

    (@pcfreak30)

    Does the transaction recording go any deeper? Can you use newrelic? Other option is using xhprof, though that can be a bit of a pain to setup as your on your own mostly https://github.com/preinheimer/xhprof.

    Thanks for looking, but I need more details to be able to trace this bottleneck 🙂

    Thread Starter Richard Vencu

    (@rvencu)

    I think I can add your account to the Blackfire organization so you can profile the load from your end. You would need to create an account first

    Plugin Author Derrick Hammer

    (@pcfreak30)

    Thread Starter Richard Vencu

    (@rvencu)

    Done and ran 2 tests with and without REDIS

    What I can see is a huge I/O wait in the wp_print_styles() that I think is used by your plugin. not sure why this happens.

    Biggest times I can see spent by admin-ajax.php during the WP Rocket preloads. Do you have an idea what url is called during preload? We should test that url as well.

    Thread Starter Richard Vencu

    (@rvencu)

    right now with the object cache enabled I cannot find the bottleneck anymore

    does redis cache get flushed at wp rocket cache flusing? if not maybe this generates the whole problem

    Plugin Author Derrick Hammer

    (@pcfreak30)

    When wp-rocket flushes, it flushes data that wp-criticalcss has stored selectively with transients (which go to object cache). See https://github.com/pcfreak30/wordpress-cache-store.

    Plugin Author Derrick Hammer

    (@pcfreak30)

    Please contact me on skype, pcfreak309 or hangouts to talk about this more.

    Thread Starter Richard Vencu

    (@rvencu)

    sent invite over hangouts. cannot literally speak now, I catched cold and lost my voice, but I can type. I also have webmetting server if you need screen sharing and control

    Plugin Author Derrick Hammer

    (@pcfreak30)

    What your email?

    Thread Starter Richard Vencu

    (@rvencu)

    Also did a bit of drilldowns myself and found the i/o time was inflated by a number of calls to the maxcdn.bootstrap.com server which I therefore tried to eliminate. wp menu is another big resource eater mainly processing time. Avada and fusion builder come next.

    So the things seem not bad with this plugin instead it calls some of the other slow things. redis helps with that up to a point (db calls)

    My main problem was that my server was sluggish during wp rocket preloads. During that window any legit visitors got huge TTFB time from the server. Still CPU and memory were under 50% so the only thing that could happen was the inflated PHP processing queue

    Thread Starter Richard Vencu

    (@rvencu)

    maybe you got invite from adwords@dentfix

    Thread Starter Richard Vencu

    (@rvencu)

    So I am satisfied now that actually my problems are not coming from this plugin. I fear more the bad redis.conf settings.

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Blackfire test, indicates big processing time for print_styles on this plugin’ is closed to new replies.