Mauricio Novelo
Mauricio Novelo
I can try to answer your questions about Sidekiq-Pro @ixti! We really appreciate all the hard work you're putting into this > * How to notify super-fetch that job was...
@ixti I'm happy to help with the Sidekiq Pro support, regardless of whether it's for 1.0.0 or later! Let me know if there's a branch you'd like me to test...
@woodhull yeah, the Sidekiq Pro code is private for paid customers. @ixti I'm still happy to help with the Sidekiq Pro support, especially if it's blocking the 1.0.0 release. At...
@ixti, let us know if we can help to move this forward!
@joevandyk below is what we're doing right now for throttling multiple jobs with a shared key (not necessarily throttling the entire queue, but if only jobs that have this throttle...
Oh that's interesting @jcsrb. We strictly use weighted queues so we've not run into that
I hear ya @davidgovea My current hypothesis is that the bottleneck for us is this query ```sql SELECT pg_namespace.oid AS namespace_id, relname, relpages, attname, pg_type.typname type_name, atttypmod type_modifier, pg_attribute.attndims ndim,...
Are you seeing this behavior for jobs on the same queue or are jobs in lower priority queues also waiting? If the latter, could you share your queue configuration?
Currently the behavior is to add the throttled job back to the queue without any changes, so its enqueued_at value stays the same. Sidekiq then prioritizes jobs in the same...