0

I'm trying out ELB with a minimal configuration (HTTP 80 -> 3000), and for one just one EC2 instance.

(I know that normally one would put at least two EC2 instances, but I'm just assessing ELB.)

I've noticed that under this setup (which I assume I've configured correctly - maybe I missed something), the response time will be exactly as slow as the Idle Connection Timeout setting I specified.

For example if the setting is 30 seconds, and I visit elb-XXXXXXXXX.eu-west-1.elb.amazonaws.com, my browser will have to wait 30 seconds for the page to load.

Same for 2, 5, 60 seconds.

Set to 1 second, I don't have to wait 1 whole second though - I can continuously re-request the page (i.e. keep the Refresh keyboard shortcut held) and I see no hiccups.

So leaving the setting to 1 seconds can be tempting - is it advisable though?

Can I get to use the recommended setting (60 seconds) with just one EC2 instance behind ELB without experiencing slowness?

deprecated
  • 153
  • 7
  • Now I just associated 5 additional EC2 instances with ELB, and the issue persits. So the problem doesn't seem to have to do with the actual number of instances behind ELB. – deprecated Oct 28 '15 at 00:12
  • 1
    Definitely not normal. I have something like 30 different ELB deployments and have never encountered this. It sounds as if your application is not behaving correctly, but in a way that is masked during direct connections. – Michael - sqlbot Oct 28 '15 at 03:22
  • Thanks so much for the insight. What kind of problem might my application (or EC2 instance) have? It's always accessed by the same port (3000), whether it's via ELB or directly. Only slow when via ELB. – deprecated Oct 28 '15 at 03:48
  • 3
    If, for example, your application writes data to the client without using chunked transfer encoding or sending an accurate content-length header, the browser could wait until the connection is closed before concluding the content has been received. I would suspect something like this based on what you have described so far. – Michael - sqlbot Oct 28 '15 at 04:45
  • The content-length header was missing, but setting it made no difference sadly. Using chunked transfer encoding is quite more complex to setup, it's not easily available in Ruby on Rails so I don't think that can be the cause...? – deprecated Oct 28 '15 at 05:58
  • One thing that I've noticed is that the EC2 server returns `Connection: close` header (keepalive is not supported in the server I want to use). Might that be the cause? – deprecated Oct 28 '15 at 05:59
  • 1
    Indirectly, yes, if the application is behaving in a not-quite-correct fashion in its handling of the http protocol. It might be worth your trouble to install nginx on the instance and proxy the traffic through it to your app, as it might correct any subtle protocol issue for you, as well as potentially maintaining keepalives between itself and the ELB. That's a pretty common configuration with a bonus of having it handle any static files directly. – Michael - sqlbot Oct 28 '15 at 06:13
  • Yes, precisely I was thinking doing that setup. Thanks so much! – deprecated Oct 28 '15 at 08:17

1 Answers1

1

Apparently, an application server (Unicorn in my case) generally must not talk directly to ELB - it must do it behind a highly specialized HTTP server such as Nginx. This is particularly true for serving static files - one does not want those to be served by Ruby!

Unicorn in particular assumes 'fast clients', a guarantee that only nginx can fulfill - not ELB.

Doing so fixed my issue.

deprecated
  • 153
  • 7