So a global variable $xx is not shared in the cloud?!
On 10 Mar, 06:49, Oren Teich o...@heroku.com wrote:
I don't have a good answer for your question, but note there is no guarantee
that your requests will be served from the same physical machine - we'll
move the dyno around as demanded by
These kinds of questions crack me up. I am going to try to adress this
without sounding rude, but if I do happen to come across as rude and I
apologize for that up front.
No, the $xx global variables are not persistent across the cloud. If
you have more than one machine then you have to jump
Yes Carl, you tone is quite rude. And perhaps you reply to the wrong
person.
By the way I need the global variable for other uses, caching is not a
problem for me.
On 10 Mar, 15:51, Carl Fyffe carl.fy...@gmail.com wrote:
These kinds of questions crack me up. I am going to try to adress this
Carl,
I think your tone is fine :-) and I appreciate you taking the time to
post your experiences. Looking forward to memcached being deployed.
Daniele,
If you really need a global variable to be accessible across servers
then memcached works good as long as it doesn't matter if that global
Thanks Chris,
the memcached solution is right but:
- it is in private beta (by the way I will send a mail to join the
beta)
- i don't know how much it will cost by I suppose that it will be too
much (form me) to just handle some Kb
What's I'm doing is a micro firewall that act as a filter
Daniele,
My apologies for coming across rude, it was not my intention, which
was why I apologized up front. As Chris said, there are better ways to
skin the global variable cat. Also, in most Ruby docs it says use them
sparingly:
http://www.rubyist.net/~slagell/ruby/globalvars.html
Which to
Hi Carl,
no problem :)
As I wrote in another post I need to use (read write) a small amount
of data (about 200Kb) in a before_filter to.
I need to operate *fast* and the DB is not a viable solution (the I
need to pack it as plugin so I prefer to don't have any DB
dependencies).
Filesystem... is
As far as I know the beta is closed, but if you're willing to wait
memcached will be rolled out to the general public soon (from what
Oren has said). I agree with everyone else, it sounds like that is your
best bet for something that's fast. I'd also look at something like
redis if you want to do
On Mar 9, 10:40 pm, Chris Hanks christopher.m.ha...@gmail.com wrote:
I'm interested in this too. I have several thousand MongoDB documents
that are read-only and frequently accessed, so I figured I'd just
cache them in the dyno's memory to speed up requests.
So is 300 MB the hard limit for
Chris,
Will this work for you? http://docs.heroku.com/http-caching
Carl
On Wed, Mar 10, 2010 at 2:22 PM, Chris Hanks
christopher.m.ha...@gmail.com wrote:
On Mar 9, 10:40 pm, Chris Hanks christopher.m.ha...@gmail.com wrote:
I'm interested in this too. I have several thousand MongoDB documents
No, I'm familiar with http caching, and it's not what I'm looking to
do. Thanks anyway, though.
What I'm doing is actually not that complex. MongoMapper already has
an identity map, I'll just be tweaking it to persist between requests.
And I'm only doing this for a few of my models (ones that are
As the document you point to indicates, 300MB is the hard limit. We
automatically kill any dyno using more than 300MB.
Oren
On Wed, Mar 10, 2010 at 12:10 PM, Chris Hanks christopher.m.ha...@gmail.com
wrote:
No, I'm familiar with http caching, and it's not what I'm looking to
do. Thanks
On Tue, Mar 9, 2010 at 11:02 PM, Alex Chaffee ale...@gmail.com wrote:
I've got some frequently-accessed data I'd like to store in RAM
between requests. I'm using Sinatra so I'll probably just use an LRU
cache in a @@class variable. I think I can muddle through all the
technical issues but
I'm interested in this too. I have several thousand MongoDB documents
that are read-only and frequently accessed, so I figured I'd just
cache them in the dyno's memory to speed up requests.
So is 300 MB the hard limit for each dyno's RAM, then? I suppose that
if it grows beyond that point, the
14 matches
Mail list logo
