Robert O'Rourke

The jobs table gets absolutely massive as each run is a new row. Could perhaps do so with a where clause for `nextrun > now()` at least but yeah -...

Ah nice. Not totally sure how to go about that with the `get_jobs_by_query()` implementation... Filtering the array after the actual db query?

Thoughts on this method? I'm seeing multiple db queries on an initial population of the jobs, then a single query for most page views thereafter.

@rmccue this is how I interpreted your comment here: https://github.com/humanmade/Cavalcade/issues/117#issuecomment-1237335606 Fetching / populating the full array of jobs once, then querying from the non-persistent cache. I'll try and figure out...

I've updated it to just do the generic query on the `pre_get_scheduled_event` hook instead.

It's not really a solid benchmark test but using `ab` locally it seems the change (applied before the 2nd run) has some improvement: ``` # ~/projects/altis-dev on git:master x [14:33:09]...

> Thanks for looking into this. Would be curious if there's a way to profile the change before and after but that sounds positive! @kadamwhite I've done a basic benchmark...

This might be a useful reference in terms of the `phpize` related steps to get the extension installed properly. https://github.com/phpredis/phpredis/blob/develop/.travis.yml

Kinda related but there's an issue with Xdebug 3 - this line: https://github.com/wp-cli/wp-cli/blob/master/php/utils-wp.php#L69 Forces the value of `display_errors` if that function exists but Xdebug can now have it's mode set...

This makes sense to me if that doesn't do anything different to what Xdebug already does. Will give it a go.