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
I just ran "dtrace" on "ruby dbcheck.rb" (sqlite test case I
mentioned earlier)
and I see:
0 18561 open:entry ruby /Library/Ruby/Site/
1.8/universal-darwin10.0/sqlite3/sqlite3_native.bundle
Which is the sqlite3 bundle that comes "with" Ruby, rather then the
bundle that
c
I can't find my second post from tonight, but I fixed the "taps" issue
by removing
sqlite3-ruby gem, per Omar Latief's suggestion - even though it
reports that "taps" depends on it.
I then ran "heroku push:db" and it reported that it pushed zero
tables. I then discovered
that of the two database
Log into the console "heroku console" then just issue "Rails.cache.clear"
and it'll all be gone.
John
--
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
Ok, I updated heroku and the problem is still there. I really don't
think it's a Heroku issue because
I can reproduce the problem simply by invoking the "taps" executable,
even without
any command line arguments:
$ taps
/Library/Ruby/Gems/1.8/gems/sqlite3-ruby-1.3.2/lib/sqlite3/
sqlite3_native.bu
We are using Dalli and the Memcache add-on and would like to flush our cache
to observe how our application behaves while the cache fills up.
Have tried this from the console:
>> t_dall.stats
=> {"mc3.ec2.northscale.net:11211"=>{"bytes"=>"88686484", "cas_misses"=>"0",
"delete_hits"=>"0", "get_hits
The Heroku gem itself can do this for you - if you put in a before or
after_filter a quick check on HTTP_X_HEROKU_QUEUE_DEPTH or
HTTP_X_HEROKU_QUEUE_WAIT_TIME
depending on your criteria, then use the gem to add or remove a dyno as
suits you. Look at
http://blog.darkhax.com/2010/07/30/auto-sca
Are there any plans for some sort of option that we can tick that will let
our applications scale to handle the load that we might get in spurts?
Reason I ask is that we've just had some TV advertising on one of our
applications and gone from 40rpm to 3,500rpm in a matter of seconds. It
would
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
Both are hosted on EC2 and have similar latency characteristics as a result.
P
On Jan 15, 2011 6:58 AM, "John Maxwell" wrote:
> Hi,
>
> I was wondering how the network response differs between using Memcached
or
> Redis on Heroku. I'm happy using either for caching my app, but I was
> wondering w
I move certain some data in and out out Heroku for processing with Redis-TG.
I've been really impressed with the performance.
On Jan 15, 2011, at 9:58 AM, John Maxwell wrote:
> Hi,
>
> I was wondering how the network response differs between using Memcached or
> Redis on Heroku. I'm happy u
Hi,
I was wondering how the network response differs between using Memcached or
Redis on Heroku. I'm happy using either for caching my app, but I was
wondering which of the services has a better link into Heroku and thus is
likely to offer better performance? (I'm not interested in a discussion
13 matches
Mail list logo
