Be faster for cache misses

[mezis]

When a request is made for something that's not in the cache, we currently synchronously fetch from upstream, and return the results.

It would be fater, in this case, to

• redirect to upstream
• asynchronously (through DJ for instance) prime the cache.

This is faster for the client on 1st request ; the drawback (which is not our concern) is 2 identical requests made to upstream.

[dawid-sklodowski]

If this is going to be run on one dyno on heroku, then asynchronously through DJ doesn't seem to be convenient option.

How about redirect to upstream, and get new version in thread?

[mezis]

How about redirect to upstream, and get new version in thread

Sounds like a plan. You could just as easily have another process running on the dyno to that effect, for instance reading from a file.

[sheerun]

Please use Sidekiq instead of DJ. It's lot faster because it uses redis and no serialization.

[mezis]

Please use Sidekiq instead of DJ. It's lot faster because it uses redis

That's only useful if you need the lower latency. Which we don't really need here—a few 10s of milliseconds is fine. Using Redis adds another dependency, which adds cost (servers + maintenance), so in my humble opinion that's a bad compromise.

DJ is easier to integrate and just needs Rake and an ActiveRecord-supported DB, which is right there for free on Heroku.

and no serialization.

Sidekiq does serialize as objects can't magically be passed between processes. It might use Marshal instead of Yaml though :smile:

[sheerun]

I promise you'll regret it :D

[mezis]

I promise you'll regret it :D

Hum, probably not. We're running a fairly big website @HouseTrip, running short of a million background jobs daily, and very smoothly. Guess what: that's backed by DJ. We changed the backend from ActiveRecord to Mongo when we needed the extra scalability (a year back, roughly) ; it works fine until now.

We'll probably consider switching to something Redis-backed (or write a Redis backend for DJ) when our needs grow by x5 or x10, but definitely not needed yet.

And definitely not needed for Yarp, which most users use only locally, and gets only a few requests per minute for now.

This being said: if you're willing to write Sidekiq based background processing support for Yarp, and it's an optinal extension (you wouldn't want to impose it to all users, who may not want to run a Redis server), I'll definitely merge it!

[sheerun]

Actually Sidekiq is compatible with delayed job (you can use .delay method). Sidekiq comes with nice web panel and middleware extensions, but I understand your reasoning. Use delayed job if you're comfortable with it.

This conversation made me think why there is no background job abstraction like Faraday for HTTP. Probably there aren't that much backends.