@1c7 https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server is a pretty good writeup heroku did after recommending switching from unicorn to puma
Hello. I am using puma for multiple workers, not threads (i.e. --workers N --threads 1:1), as each worker is not threadsafe (or at least the work hasn't been done yet to confirm thread safety). My understanding is that if a request in each worker takes one second to complete, and I send in two requests concurrently, each client should have an overall response timing of near to one second. However, it seems that puma is blocking, as these two concurrent requests seem to take nearer to two seconds. Am I misunderstanding something, or is this a bug, or some GIL issue? (this is MRI). Either way, I'd like to understand more :)
I can also produce a small rack-based example of the problem if needed.
*even if
OK, so I think the issue is
queue_requests being true, combined with only one thread per worker. As I understand, a worker in any state would be selected to handle the request. When there are multiple threads, this issue does not arise. Setting queue_requests to false fixes this.
Should there possibly be a warning raised if threads are 1:1 and
queue_requests is true? It seems like this is a bad default in this situation.
! Terminating timed out worker: 27501
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27504
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27508
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27513
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27504
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27508
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27513
this happens almost immediately after a restart of the Puma service
the machine resources barely scratch 5%
puma is logging all requests as 127.0.0.1 instead of their IP Address I am using the X-Forwarded-For header in nginx, my nginx is custom compiled using chef omnibus if that makes a difference. Trying to debug so my request isn't 127.0.0.1, actual ip is (10.10.20.137). Any pointers?
ip is 216.x.x.x so it isn't even an internal address.
one thing unique to me is I am using chef omnibus so everything is compiled manually nginx, ruby, etc.
I took something from gitlab-ce to get to work locally https://gitlab.com/gitlab-org/gitlab-ce/blob/08264f4334ff48d1274f066cd5b03455bc4befdf/config/initializers/trusted_proxies.rb
I am just whitelisting ::1 and 127.0.0.1 nothing else
I think something in your middleware is doing the wrong thing. Take a look at this issue on puma/puma: https://github.com/puma/puma/pull/873#issuecomment-178099895
Try adding this to your Puma config:
set_remote_address header: "X-Forwarded-For”
trying the puma configuration change
still seeing 127.0.0.1
I didn’t have to do anything special for Puma to parse X-Forwarded-For from Varnish and HAproxy, so this is all a bit mysterious
i am wondering now if the rollbar gem could be causing this
But even that should only scrub the headers that get sent to Rollbar, and not actually remove them from the rack request.
My rails app is too slow