A cautionary tale:
We recently attempted a migration from Paperclip to Carrierwave (0.4.10).
Despite working fine locally, we hit a snag as soon as we went live with it in
production:
Carrierwave would block for inordinate amounts of time. Never found out why, it
just did.
Heroku would timeo
Hi, folks.
In my app, when the server was uploading a file to S3 (fired from a first
request), we got a request timeout error from heroku when the app received a
second request. The solution was to use DJ in order to not block the dyno,
and manage the upload from the job in the worker in backgroun
Right, that's more of a limitation that I thought apologies for being wrong
(and sure I wasn't!) - I'm not massively familiar with Rack, but could you
use a Rack Middleware to detect a file upload and spin up another dyno
whilst it is in progress? Or is that not detectable within Rack?
--
You
A dyno is the entire stack. A request, the second it hits Heroku,
blocks a dyno. This could be because your application is processing,
or because you are handling an upload.
If you are doing decent size upload, you should have your app upload
directly to S3.
Oren
On Sun, Jan 16, 2011 at 12:33
Yeah - that is talking about the outgoing hop to S3 from Heroku - which is a
blocking I/O, not the incoming step into Nginx... Any word on this from an
official source?
--
You received this message because you are subscribed to the Google Groups
"Heroku" group.
To post to this group, send emai
there's a bit at the bottom of this page http://docs.heroku.com/s3 that may
give an additional clue
"This is the preferred approach if you’re working with file uploads bigger
than 4mbs. The idea is to skip the hop on your application dyno, making a
connection from the end user browser straight
Having searched the docs for confirmation on this, there isn't anything
which explicitly says what the situation is.
However, unless I'm being a plonker, which is possible - then nginx only
reroutes the request to the dyno once the request is complete - ie the file
has been received. Otherwise
I wouldn't call it rerouting, but it is likely a response to a TCP transaction.
Nginx is just a reverse proxy routing requests to the dynos in the first place.
This is what large scale deployments do anyway, so it's nothing new.
By the way, this is nothing that isn't written on the Heroku docs..
So the dyno then reroutes requests back to Nginx? really?
--
You received this message because you are subscribed to the Google Groups
"Heroku" group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com.
I think it's more precise to say that a dyno is a thin+rack combo, so the dyno
*is* the web server receiving the request.
Jimmy
On Jan 15, 2011, at 2:54 PM, John Maxwell wrote:
> So an upload to your app on heroku blocks the whole dyno whilst it is
> uploading? Surely that isn't right - as th
So an upload to your app on heroku blocks the whole dyno whilst it is
uploading? Surely that isn't right - as the dyno shouldn't even be aware of
the post request until the web server itself has received the whole file? In
that case its just blocked whilst the app processes it?
--
You received
Hi Tobes,
Not sure if this overlaps, but something else to consider:
http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?uploadobjusingmpu.html
Good luck,
Keenan
On Jan 13, 2011, at 3:33 PM, Jimmy Thrasher wrote:
> Hi Tobes,
>
> Unless they've removed the 30s hard limit, you shou
Hi Tobes,
Unless they've removed the 30s hard limit, you should see those requests
dying after 30s, but yes, in theory if it takes 10 minutes it blocks your
upload.
An approach I like but have never had the need to implement would be to use
the "upload by POST" technique, described here:
http://a
Hi guys
Sorry, this is a lazy question...
If we have 1 dyno, and a user uploads a file that takes 10 minutes,
will the other requests to the app be blocked for 10 minutes?
Looking at our logs it looks like that *is* the case. We do store
files on S3 btw, but our Rails app receives the file and m
14 matches
Mail list logo
