Heroku recently decreased number of available connections to production database (from 500 to 60). Opened connections were consuming a lot of memory and causing problems, so it seems like a step in right direction.
My app has more than 100 concurrent processes which all access database at same time. Heroku suggests using https://github.com/gregburek/heroku-buildpack-pgbouncer to fix this issue.
I wasn't able to find any proper guide on how to do this. I was able to install and enable buildpack, but I have no ide what these configuration variables do and how do they work. With default configuration, i get tons of ActiveRecord::ConnectionTimeoutError errors.
Does anyone has experience with this and if can please provide provide step-by-step guide on how to do this properly and how to configure everything that needs to be configured?
What version of Rails are you running on? I just deployed pgbouncer to our production webapp using these steps (for a Rails 3.2 app running on Ruby 2.0)
Create .buildpacks file in root directory app that contains the text
https://github.com/gregburek/heroku-buildpack-pgbouncer.git#v0.2.2
https://github.com/heroku/heroku-buildpack-ruby.git
I created a file called disable_prepared_statements_monkey_patch.rb in config/initializers that contained the code posted by cwninja in this thread: https://github.com/gregburek/heroku-buildpack-pgbouncer/pull/7
Modified my Procfile to add
bin/start-pgbouncer-stunnel
before
bundle exec unicorn -p $PORT -c ./config/unicorn.rb
executed
heroku config:set PGBOUNCER_PREPARED_STATEMENTS=false --app yourapp
heroku config:add BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git --app yourapp
deployed the new .buildpacks and Procfile changes to production
It worked as advertised after that point. The first time I deployed I neglected to disable prepared statements, which caused my application to blow up with lots of 'duplicate prepared statement errors'. If you're using Rails 4.1 or above the monkey patch is apparently not necessary, however I guess there's a bug in Rails 3.2 that doesn't parse pgbouncer's change to the database URL in such a way that prepared statements are actually disabled.
Related
I'm new in rails app development I am little bit confusing about rails deployment.
I following this guide below and done at all.
That mean my rails app on production mode?
Need to change Puma RACK_ENV to 'production' in Profile before pushing to heroku?
https://devcenter.heroku.com/articles/getting-started-with-rails4
I believe so. The entire tutorial is setting up your rails server to work in production mode. Using some inductive logic, it seems that the tutorial is assuming you're in production:
"Rails 4 no longer has a static index page in production. When you’re
using a new app, there will not be a root page in production, so we
need to create one. We will first create a controller called welcome
for our home page to live:"
Indicates to me that it's assuming your rails server will be running in production.
To make doubly sure, you can check the heroku logs and look for a line that says:
Rails [your version] application starting in production
I have a JRuby on Rails application, which is usually deployed as war to Tomcat. In development mode we use either WEBrick or trinidad (usually first). Now we are considering using Toquebox.
I was able to deploy app using Torquebox, but I wonder where can I find development logs (things like request/response details, executed SQL queries etc). I got used to that stuff. JBoss'es console, boot.log and server.log don't contain those - only torquebox specific logging.
Thanks
When you are currently in your applications directory, use
$ less log/development.log
For every enviorement: env
$ less log/<env>.log
For following it (as it appends) use:
$ tail -f log/<env>.log
Is there an issue with developing my site on my macbook and then moving to a server when done? Will there be issues I need to plan ahead for? DB or ruby related maybe? Dependencies or something a server could have different from my dev environment that could cause a nightmare later? I'd rather develop it offline since it'd be faster and wouldn't require an internet connection but in the past I've always done everything with live sites so this would be a first, and I am new to ruby on rails.
Developing locally and then deploying to your server(s) via something like capistrano is standard practise.
It's a good idea to keep your development environment as close as possible to your production environment (ruby versions, database versions etc). Bundler makes keeping your gems in sync easy
I used Heroku for some projects. The deployment was as easy as it could be. I just did a git push and it worked without problems... I really like bundler and rake :-)
Your Question embodies THE way to develop in Rails. Your development environment is an offline representation of what you're production site will be.
A quick workflow analysis for you could be:
rails new ~/my_app -d postgresql; cd ~/my_app; rm public/index.html
Next, create the database:
bundle exec rake db:create:all
Now you'll have the db and app all set up, let's set up your main pages:
bundle exec rails generate controller Site index about_us contact_us
Now you'll have something to see on the site, so run:
bundle exec rails server
This server acts as your offline connection and will handle the rendering of any text, images, html etc you want to serve in your rails app. Now you can join in the debates of TDD, to TATFT or JITT, rspec vs test::unit. Welcome.
Developing locally is definitely the way to go. However, I would look into getting it on production as soon as possible and pushing often. This way you can see changes happen as you make them and are aware of any possible breaking changes.
I use heroku a lot and when I start a new project I push it to heroku almost immediately. While developing, I can publish new changes simply by git push heroku master. Everyone has to find their own workflow, but this has always worked well for me.
If you are interested in Heroku here is a good link to get you started:
https://devcenter.heroku.com/articles/rails3
I'm trying to create a migration for my app, and in this app I'm using a gem that tries to startup a different service upon app startup. Apparently, creating a migration...
rails generate migration AddSomeStuffToTable stuff:string
...activates the app, and this gem which tries to connect to startup the service. It appears that starting up the app via generating a migration makes the service startup unable to connect, so it just keeps sleeping and trying again, never actually running the migration.
In this gem, I've already dealt with this for rake, so this is what I've got so far:
MyService.start unless defined? Rake or defined? IRB
This handles the rake problem (like rake db:migrate, rake db:populate), but how can I handle the creation of migration, which (as far as I know) is not a Rake task?
You could try using environment variables for disabling the service:
MyService.start unless ENV['NO_SERVICE']
And run your command like this:
NO_SERVICE=1 rails generate migration AddSomeStuffToTable stuff:string
However, I doubt this scales well, especially if multiple developers are in the app. A better approach might be to do the reverse of this, to only start the service if a particular env variable is present. However, going this direction, you'd need to make sure your app servers set this variable, for example:
Apache: SetEnv START_SERVICE 1
nginx: env START_SERVICE=1
thin: START_SERVICE=1 thin start
I am working my way through Michael Hartl's Ruby on Rails Tutorial (on Mac OSX 10.7.2/Ruby 1.9.2/Rails 3.1.1) and just finished Chapter 2, which concludes with deploying a demo twitter app to Heroku.
Everything appears to be working properly when I run the app locally AND I was able to successfully deploy the app to Heroku in some capacity because it is available here: http://rich-twitter-baby.heroku.com/
However, what I can't figure out is why the /users and /microposts pages aren't showing up publicly (with lists of users and microposts respectively) as they do locally. I migrated my database to Heroku and pushed the info up there and everything seemed to work properly, but I get this error message when I try to view the pages publicly.
I've tried running "heroku console" but get this error:
Unable to attach to a dyno to open a console session.
Your application may have crashed.
Check the output of "heroku ps" and "heroku logs" for more information.
And the logs say error H13, while the ps looks like this:
Process State Command
------------ ------------------ ------------------------------
web.1 idle for 1h thin -p $PORT -e $RACK_ENV -R $HER..
Let me know if anyone has any ideas or if more info would help.
Thanks!
I would contact Heroku support on this. Dynos can crash and become 'zombiefied' which means they just sit there idle.
Normally these will clear themselves out within a few hours, but it shouldn't happen that often if at all.
Doing a new deploy will also normally restart everything back to clean.
If it's consistently happening, have you tried spinning up the application locally in production mode to try and reproduce the problem
rails server -e production
, or adding something like the Airbrake add-on to your app to capture the error.
Check your log using
$> heroku logs
At the command line of your development system that you used to push to heroku.
Post the log here if you can't figure it out from that.
I contacted Heroku Support about this issue and it turns out that the answer had to do with which stack my app was being deployed to. I did their workaround and everything is now up and running. Here's the full info from them:
It looks like the problem is that you're using Rails 3.1 and our Bamboo stack; we have full >asset pipeline support on our Cedar stack[1]. Since this is just a demo app, an easy >workaround is to precompile locally and commit the files:
rake assets:precompile
git add -A
git commit -m "precompiling assets"
git push heroku master
To get full asset pipeline support, you need to create your app on the Cedar stack and then >repeat the process you did to get your Bamboo app to work.
[1]: http://devcenter.heroku.com/articles/rails31_heroku_cedar