Redis Keyspace Scanning Entire Question

[tmedford]

"It is recommended that a production deployment of resque-scheduler be hosted on a dedicated Redis database. While making and managing scheduled tasks, resque-scheduler currently scans the entire Redis keyspace, which may cause latency and stability issues if resque-scheduler is hosted on a Redis instance storing a large number of keys (such as those written by a different system hosted on the same Redis instance)"

Can you please refer to the section of code that does this? Would it be advised to keep session storage in one redis database and queuing jobs in another on the same redis instance?

[rafaelfranca]

It is here

resque-scheduler/lib/resque/scheduler/delaying_extensions.rb

Lines 188 to 211 in 78c5325

	# Given a block, find jobs that return true from a block
	#
	# This allows for finding of delayed jobs that have arguments matching
	# certain criteria
	def find_delayed_selection(klass = nil, &block)
	raise ArgumentError, 'Please supply a block' unless block_given?
	timestamps = redis.zrange(:delayed_queue_schedule, 0, -1)
	# Beyond 100 there's almost no improvement in speed
	found = timestamps.each_slice(100).map do |ts_group|
	jobs = redis.pipelined do |r|
	ts_group.each do |ts|
	r.lrange("delayed:#{ts}", 0, -1)
	end
	end
	jobs.flatten.select do |payload|
	payload_matches_selection?(decode(payload), klass, &block)
	end
	end
	found.flatten
	end

.

I'd not mix session storage and queuing job in the same redis stance. They have different resiliency requirements.