Closed hotrungnhan closed 2 months ago
Can you share the query that you're seeing from Bullet? I'm curious if you can give a few more details about where in GoodJob it's causing N+1s.
Generally I try to avoid counter-caches in GoodJob because frequently jobs are added or deleted without invoking Active Record callbacks (for performance). But there shouldn't be N+1s.
it in batch page of dashboard, it count jobs for each batch which lead to N+1. @bensheldon if It a performance pain if we use CC for that case. i suggest we can using an short term cache when the total of jobs is huge such:
https://github.com/flyerhzm/bullet
When i install good_jobs in my project, and try with the dash board. Bullet has told me that we can improved the performance of GJ by using counter cache.
It alert on:
* `GoodJob::BatchRecord` on `jobs` relationship
Hi, I am not using batch or a maintainer but maybe as a workaround while this gets checked out you could try a gem like goldiloader
to handle N+1 automatically for you. You can enable it per request as such
prepend_around_action :set_request_eager_loading, if: -> {...something like controller_path == "good_job/..." }
private
def set_request_eager_loading(&block)
Goldiloader.enabled(&block)
end
Let me know if it helps! This saved me a few times :)
I looked into this:
Here's the controller, which has a filter object:
The filter object does have an includes(:jobs)
, so it should be preloaded:
Nuts! In the template it calls jobs.count
which always emits a query, whereas it should be jobs.size
🤦 :
https://github.com/flyerhzm/bullet
When i install good_jobs in my project, and try with the dash board. Bullet has told me that we can improved the performance of GJ by using counter cache.
It alert on:
GoodJob::BatchRecord
onjobs
relationship