Webui slow on login


#1

My chef server is mostly performing fine, but there seems to be a
consistent 20-30 second hang when loading the webui initially. It is
better after you’ve logged in and loaded the first page. Has anyone
seen this that can point me in the right direction? My users aren’t
thrilled with the experience.

This is chef server 0.10.4 served via unicorn (server and webui) with
an nginx proxy. All on one VM. Here are a couple examples where you
can see the action_time is over 20 seconds. Seems to always be on the
same action/controller. As noted, most other commands have an
action_time consistently under 1 second.

unicorn-webui.stdout.log.9.gz: ~ Started request handling: Wed Feb 15
15:30:29 -0800 2012
unicorn-webui.stdout.log.9.gz: ~ Params: {“action”=>“index”,
“controller”=>“nodes”}
unicorn-webui.stdout.log.9.gz: ~ {:dispatch_time=>23.639048,
:before_filters_time=>0.11601, :action_time=>23.638479,
:after_filters_time=>1.3e-05}
unicorn-webui.stdout.log.9.gz:–
unicorn-webui.stdout.log.9.gz:
unicorn-webui.stdout.log.9.gz: ~ Started request handling: Wed Feb 15
16:31:36 -0800 2012
unicorn-webui.stdout.log.9.gz: ~ Params: {“action”=>“index”,
“controller”=>“nodes”}
unicorn-webui.stdout.log.9.gz: ~ {:dispatch_time=>24.572686,
:before_filters_time=>0.116543, :action_time=>24.572283,
:after_filters_time=>0.000126}
unicorn-webui.stdout.log.9.gz:–
unicorn-webui.stdout.log.9.gz:
unicorn-webui.stdout.log.9.gz: ~ Started request handling: Wed Feb 15
17:42:09 -0800 2012
unicorn-webui.stdout.log.9.gz: ~ Params: {“format”=>nil,
“action”=>“index”, “controller”=>“nodes”}
unicorn-webui.stdout.log.9.gz: ~ {:dispatch_time=>24.371573,
:before_filters_time=>0.392109, :action_time=>24.371188,
:after_filters_time=>2.7e-05}

Thanks,

KC


#2

On Fri, Feb 24, 2012 at 4:48 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

My chef server is mostly performing fine, but there seems to be a
consistent 20-30 second hang when loading the webui initially. It is
better after you’ve logged in and loaded the first page. Has anyone
seen this that can point me in the right direction? My users aren’t
thrilled with the experience.

I’ve not used unicorn yet since I’ve been stuck at Java shops but back
in the Passenger days, there would always be that same delay depending
on how frequently the application was accessed. Passenger had an
option added in 3 I think that allowed you to have a base pool size
that would be kept around regardless. I thought unicorn spun up
instances on demand? Maybe that’s the thing you’re waiting for?

This is chef server 0.10.4 served via unicorn (server and webui) with
an nginx proxy. All on one VM. Here are a couple examples where you
can see the action_time is over 20 seconds. Seems to always be on the
same action/controller. As noted, most other commands have an
action_time consistently under 1 second.

unicorn-webui.stdout.log.9.gz: ~ Started request handling: Wed Feb 15
15:30:29 -0800 2012
unicorn-webui.stdout.log.9.gz: ~ Params: {“action”=>“index”,
“controller”=>“nodes”}
unicorn-webui.stdout.log.9.gz: ~ {:dispatch_time=>23.639048,
:before_filters_time=>0.11601, :action_time=>23.638479,
:after_filters_time=>1.3e-05}

How many nodes do you have registered?

Thanks,

KC


#3

On Fri, Feb 24, 2012 at 1:52 PM, John E. Vincent (lusis)
lusis.org+chef-list@gmail.com wrote:

On Fri, Feb 24, 2012 at 4:48 PM, KC Braunschweig
kcbraunschweig@gmail.com wrote:

on how frequently the application was accessed. Passenger had an
option added in 3 I think that allowed you to have a base pool size
that would be kept around regardless. I thought unicorn spun up
instances on demand? Maybe that’s the thing you’re waiting for?

Unicorn forks all its workers ahead of time. On this box I have 4
workers for the server api and 3 for the webui. I could bump it up but
it’s only a 2 core VM and the recommendations I’d seen were that more
workers than cores wasn’t really needed except if you’re waiting on
i/o since queuing can happen in nginx. BTW, cpu load is low. Usually
below .4 but seems to climb to around 1 during this lag event.

How many nodes do you have registered?

829