Delivery of images - does it always hit the rack app?

[jebw]

Hi,

I'm trying to understand how dragonfly works. The urls for the images
start with /media..... but theres no media folder under public. Does
this mean that any image requests are having to hit the rack app in
order to receive the image?

I had assumed that once an image was accessed, if it didn't already
exist at the desired size, it would be resized and saved to the public
folder for future reuse??

Does the use of rack::cache mean that it is relying on a reverse proxy
in front to cache the resized images?

Thanks

jebw

[Walter Lee Davis]

On Feb 22, 2012, at 10:01 AM, jebw wrote:

> Hi,
>
> I'm trying to understand how dragonfly works. The urls for the images
> start with /media..... but theres no media folder under public. Does
> this mean that any image requests are having to hit the rack app in
> order to receive the image?

That route initiates a request through Rack on the first such request, correct.

>
> I had assumed that once an image was accessed, if it didn't already
> exist at the desired size, it would be resized and saved to the public
> folder for future reuse??

If the url (which encodes the combination of base image + any transformation) results in a cache hit, then that's the end of it -- the request is satisfied from the cache and the Rack app is a no-op.

>
> Does the use of rack::cache mean that it is relying on a reverse proxy
> in front to cache the resized images?

I'm not sure what the explicit mechanism is for filling the cache, but it does seem to work.

Walter

>
> Thanks
>
> jebw

[Jeremy Wilkins]

Thanks for the response Walter, if theres a cache hit - what is delivering that image?

My setup will be Apache + Passenger - if a user is downloading a large file, and its found in the cache, presumably the rails app will be tied up for the duration it takes to deliver that file?

Where as if its on the filesystem and handled by Apache itself (as opposed to Passenger) then Apache is multithreaded and can continue processing other requests? Have I got this right?

My consideration is that Varnish will not be in front of this lot, and Rack::Cache means Passenger gets tied up?

Thanks

jebw

[Walter Lee Davis]

On Feb 22, 2012, at 10:35 AM, Jeremy Wilkins wrote:

> Thanks for the response Walter, if theres a cache hit - what is delivering that image?
>
> My setup will be Apache + Passenger - if a user is downloading a large file, and its found in the cache, presumably the rails app will be tied up for the duration it takes to deliver that file?
>
> Where as if its on the filesystem and handled by Apache itself (as opposed to Passenger) then Apache is multithreaded and can continue processing other requests? Have I got this right?
>
> My consideration is that Varnish will not be in front of this lot, and Rack::Cache means Passenger gets tied up?

I'm out of my depth on that question, hopefully someone else will step in who understands the path that Rack::Cache uses. Given my own experience, I would guess (based on observed performance) that Passenger is not involved, but I would defer to anyone who actually knows.

Walter

[Mark Evans]

Hi - Rack::Cache is indeed a reverse proxy which sits in front of your Rails app, however it is mounted (by default) as a middleware so will be part of the same process, in other words, yes, your Rails server process (Passenger) IS tied up while it's delivering that file (though of course no processing is done as it's cached).

For better performance, you could use Varnish instead, as you mentioned, or you could make use of Dragonfly's "remote_url" functionality (http://markevans.github.com/dragonfly/file.ServingRemotely.html)

Although the example of "remote_url" in the doc is for S3, it would also work for the default file datastore, which by default saves content under the public folder, so calls to "model.attachment.remote_url" then go to public/xxxx, which depending on your Apache configuration, can be served directly (not through Rails).

As per the doc though, this way you'll have to think a bit more about whether you create thumbnails on-upload/on-the-fly, etc.

Hope that helps

Mark

[Frederick Cheung]

On 22 Feb 2012, at 16:05, Mark Evans wrote:

> Hi - Rack::Cache is indeed a reverse proxy which sits in front of your Rails app, however it is mounted (by default) as a middleware so will be part of the same process, in other words, yes, your Rails server process (Passenger) IS tied up while it's delivering that file (though of course no processing is done as it's cached).
> For better performance, you could use Varnish instead, as you mentioned, or you could make use of Dragonfly's "remote_url" functionality (http://markevans.github.com/dragonfly/file.ServingRemotely.html)

Another relatively easy option is cloudfront. Assuming you've setup a cloudfront distribution with your app as the origin

Dragonfly::App[:images].configure do |c|
if Rails.env.production?
c.url_host = 'http://xxxx.cloudfront.net'
end
end

will serve dragonfly assets via cloudfront (obviously change xxxx to you distro's id). Your app will only serve the file when the edge location doesn't have the file, and only the first of those won't be from the cache.

Fred

[Jeremy Wilkins]

Hi All,

Thanks for the answers - sounds like my primary concern does indeed apply then. This seems to come down to the fact Varnish sits in front of Apache/Ngninx, and Rack::Cache sites behind.

Thanks, jebw

[Mudiagahn Ugbowanko]

Sorry to jump in on this but for a site that uses rails+apache+passenger what is the solution in laymen terms?