Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Wrap all HTTP requests in a 5 second timeout #144

Closed
wants to merge 1 commit into from

2 participants

@croaky
Owner
  • Web requests should be typically processed in no more than 500ms, and ideally under 200ms.
  • Even though an error page will be issued to the client, and the connection terminated, when a timeout occurs the web process is still left to process the request. Subsequent requests may then be routed to the same process which will be unable to respond, causing further degradation.
  • rack-timeout ensures processes don’t remain tied up after 5 seconds of inactivity.

https://devcenter.heroku.com/articles/request-timeout

@croaky croaky Wrap all HTTP requests in a 5 second timeout
* Web requests should be typically processed in no more than 500ms, and
  ideally under 200ms.
* Even though an error page will be issued to the client, and the
  connection terminated, when a timeout occurs the web process is still
  left to process the request. Subsequent requests may then be routed to
  the same process which will be unable to respond, causing further
  degradation.
* rack-timeout ensures processes don’t remain tied up after 5 seconds of
  inactivity.

https://devcenter.heroku.com/articles/request-timeout
9ae9332
@jferris
Owner

Another benefit: this makes it less likely that a user sees a timeout page and the change they were trying to make actually went through (ie, their credit card is charged but they see a generic error page).

Looks good to me.

@croaky croaky closed this
@croaky
Owner

Thanks, Joe. I added your comment to the commit message, which changed the hash to 3f444c8, and merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 24, 2013
  1. @croaky

    Wrap all HTTP requests in a 5 second timeout

    croaky authored
    * Web requests should be typically processed in no more than 500ms, and
      ideally under 200ms.
    * Even though an error page will be issued to the client, and the
      connection terminated, when a timeout occurs the web process is still
      left to process the request. Subsequent requests may then be routed to
      the same process which will be unable to respond, causing further
      degradation.
    * rack-timeout ensures processes don’t remain tied up after 5 seconds of
      inactivity.
    
    https://devcenter.heroku.com/articles/request-timeout
This page is out of date. Refresh to see the latest.
View
5 lib/suspenders/app_builder.rb
@@ -143,6 +143,10 @@ def configure_time_formats
copy_file 'config_locales_en.yml', 'config/locales/en.yml'
end
+ def configure_rack_timeout
+ copy_file 'rack_timeout.rb', 'config/initializers/rack_timeout.rb'
+ end
+
def configure_action_mailer
action_mailer_host 'development', "#{app_name}.local"
action_mailer_host 'test', 'www.example.com'
@@ -230,6 +234,7 @@ def customize_error_pages
style_tags =<<-EOS
<link href='/assets/application.css' media='all' rel='stylesheet' type='text/css' />
EOS
+
%w(500 404 422).each do |page|
inject_into_file "public/#{page}.html", meta_tags, :after => "<head>\n"
replace_in_file "public/#{page}.html", /<style.+>.+<\/style>/mi, style_tags.strip
View
1  lib/suspenders/generators/app_generator.rb
@@ -109,6 +109,7 @@ def configure_app
build :configure_action_mailer
build :configure_time_zone
build :configure_time_formats
+ build :configure_rack_timeout
build :disable_xml_params
build :add_email_validator
build :setup_default_rake_task
View
1  templates/Gemfile_clean
@@ -6,6 +6,7 @@ gem 'high_voltage'
gem 'jquery-rails'
gem 'pg'
gem 'psych'
+gem 'rack-timeout'
gem 'rails', '>= 3.2.11'
gem 'simple_form'
gem 'strong_parameters'
View
1  templates/rack_timeout.rb
@@ -0,0 +1 @@
+Rack::Timeout.timeout = (ENV['TIMEOUT_IN_SECONDS'] || 5).to_i
Something went wrong with that request. Please try again.