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 most people means, avoid at all costs. You can put them in the db. If they are constant and never change, you can put them in config. If they are client specific, put them in a cookie and store them in the browser (as long as they aren't huge). If they are huge, then the database is your best bet because you don't want to clutter your memory with it. If the database is to slow, then put it on the file system. But whatever you do, please avoid using global variables. I have googled for the article that explains why, but I can't find it. All I could find was a repeat of the "use sparingly". As I said earlier, benchmark the easiest solution first. It might just meet your needs. On Wed, Mar 10, 2010 at 10:38 AM, Chris <[email protected]> wrote: > 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 > variable gets expired. You need to store the variable persistent in a > database. Pull it from memcached if it's there, if not then hit the > database. (Alternatively, depending on the variable, just re-create > it if it's expired and doesn't need to be persisted somewhere.) > > -Chris > > On Wed, Mar 10, 2010 at 11:51 PM, Carl Fyffe <[email protected]> wrote: >> 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 through very >> complex hoops to get them to share memory like that. >> >> First, before you start jumping through creating crazy caches in >> memory you should benchmark your app to ensure that it permorms at a >> respectable level with the number of users you expect. If it doesn't >> the first thing you should do is increase the dynos and see if that >> helps. If it does, stop working on the caches and deploy! An extra $32 >> a month is far less than the pain and heartache and time you will >> waste trying to create a frakencache. >> Secondly, caching in memory isn't very useful if you only have 12 >> users and only use one dyno. If you have many users and multiple dynos >> then caching in memory makes even less sense because you will almost >> certainly be getting cache misses all the time because the users are >> not guarenteed to return to the same dyno. >> >> If caching is absolutely neccessary beg your way into the private beta >> for memcached or wait until it becomes public. However there are >> pretty solid caching mechanisms already in place, see more below. >> >> Do people normally write large apps in Sinatra? I thought it was meant >> for dinky one off apps.... If you were using Rails the caching would >> be taken care of for you and you wouldn't have to ask these questions. >> Basically all of the suggestions you have posted are less than >> adequate answers that have been answered by the guys that wrote the >> frameworks. Use the best practices of the frameworks and you should be >> fine. But in the end let the benchmarks be the measure for the work >> you have to do. >> >> On one project a collegue sys admin wanted to keep adding memory to >> make the app run faster. I asked him to setup multiple app servers and >> load balance instead. Both looked to perform the same, until we >> benchmarked it. Multiple app servers blew the monster memory app >> server away. >> >> Benchmark twice, code once as my carpenter father would say. >> >> On 3/10/10, Daniele <[email protected]> wrote: >>> So a global variable $xx is not shared in the cloud?! >>> >>> On 10 Mar, 06:49, Oren Teich <[email protected]> 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 the cloud. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Heroku" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/heroku?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Heroku" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/heroku?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
