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 <carl.fy...@gmail.com> 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 <to...@vitamino.it> wrote: >> 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 the cloud. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Heroku" group. >> To post to this group, send email to her...@googlegroups.com. >> To unsubscribe from this group, send email to >> heroku+unsubscr...@googlegroups.com. >> 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 her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > 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 her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
