If you think that its dying when the slug is being compiled, or you just want to improve your slug loading time, you might want to tell it which parts of your repo are not needed during runtime.
some common things to add to your .slugignore file *.psd *.pdf test spec doc you might also check if any of your vendored gems/plugins are not needed during runtime (testing related stuff most likely) The point is not that having these components is slowing down runtime (though they might, slightly), but rather that including them in the slug will slow down the spin-up time for no good reason. you can find out more at: http://docs.heroku.com/slug-compiler On Sat, Aug 28, 2010 at 3:42 PM, Dennis <dennismaj...@gmail.com> wrote: > I think I have to agree with Stefan - *particularly* when it comes to > staging. Why not take the cheapest entry level package for staging for > a month - any outfit that advertises "rock solid ruby platform" > should give good to excellent service for even the cheapest "paid-for" > package. > > I totally agree with your previous post and its sentiments - the need > to be aware of, and working on, the problem when the client calls at > 2:00 a.m. is critical - it has to be one of the worst feelings ever to > have your client inform you the site is down and not be aware of it. > > However the discussion started on the topic the free account's > (staging) performance ... doesn't surprise me it's poor to fair ... > > > On Aug 28, 1:43 pm, David <datab...@gmail.com> wrote: > > It's in the best interest of any web site operator to know when their > > web site is down external from your hosting company regardless of > > platform, language, or baseline hosting provider's functionality. > > When I get a phone call at 2am that the web site is down, I should > > already be on it. > > > > It just happens that it has the same benefits for spun down processes. > > > > I understand where you're coming from in regards to all the free sites > > but most likely the operators of those sites are leveraging Varnish > > and site monitoring is simply going to hit the same cached route. We > > can only work with what we have, if they want it done differently - > > give us the option. Besides, I pay plenty a month for it to work in > > my situation. > > > > /david. > > > > On Aug 27, 10:52 am, Stefan Wintermeyer <stefan.winterme...@amooma.de> > > wrote: > > > > > > > > > Am 27.08.2010 um 15:27 schrieb David: > > > > > > That's what we do, setting up site monitoring is part of my normal > > > > routine so I have something checking the site every 5 mins including > > > > staging. > > > > > I think that might not be in the best interest of the Heroku guys. If > they wanted it that way they'd have built it in. > > > > > Stefan > > > > > -- > > > AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied --> http://www.amooma.de > > > Geschäftsführer: Stefan Wintermeyer, Handelsregister Montabaur B14998 > > > > > Asterisk 1.6:http://das-asterisk-buch.de > > > Ruby on Rails 3:http://ruby-auf-schienen.de > > > Videos and slides of AMOOCON:http://amoocon.de > > -- > 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<heroku%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- -John -- 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.
