[wp-trac] [WordPress Trac] #46645: Site health: timeout on the "Info" tab

[WordPress Trac]

#46645: Site health: timeout on the "Info" tab
--------------------------+---------------------
 Reporter:  azaozz        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.2
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  site-health   |     Focuses:
--------------------------+---------------------

Comment (by azaozz):

 > I would argue that large node_modules directories are an edge case

 Yep, I agree. But a production site may have git or svn checkouts of
 plugins. These tend to have few thousands extra files in them too. Imagine
 that times 50 :)

 > Potential slowdown areas that stand out

 Was just thinking the same. Even if we get the actual delay of making that
 wp.org API call, there are numerous other delays/slowness that we will
 need to account for to be able to catch all edge cases like DB on
 different server, other API calls, etc.

 1. Best would be to get the `$start_execution_time` as soon as WP starts
 to load, perhaps at the top of `wp_initial_constants()`. Thinking it would
 be better to have a new constant instead of reusing the `$timestart`
 global.

 2. Currently we test the max time in the middle of the loop `$runtime = (
 microtime( true ) - $start_execution_time );`, but in one test I saw it
 failing just after that at `$size += $file->getSize();` (since that's
 somewhat slow filesystem operation). The runtime test will need to account
 for the time needed to finish running PHP. Don't see a good way to
 "predict" how long that may take. Seems 1-2 seconds should be plenty.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46645#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform