Dashboard Tab Becomes Unresponsive
6 views
Skip to first unread message
Jerry Browne
Jul 15, 2010, 3:17:36 PM7/15/10
to OpenACD
I've been running some load tests against the SipXecs/OpenACD alpha
integration.
During these load tests we consistently have the Agent UI go
unresponsive when we are viewing the Dashboard. When you first load
it up, it seems like it does pretty well. However, over time it gets
less and less responsive until ultimately you have to kill the process
since it's completely locked up.
The load that I've been running is ... at most
100 agents logged in
130 load channels running
Call durations of anywhere from 15 to 75 seconds
I've been using Firefox.
Thoughts?
integration.
During these load tests we consistently have the Agent UI go
unresponsive when we are viewing the Dashboard. When you first load
it up, it seems like it does pretty well. However, over time it gets
less and less responsive until ultimately you have to kill the process
since it's completely locked up.
The load that I've been running is ... at most
100 agents logged in
130 load channels running
Call durations of anywhere from 15 to 75 seconds
I've been using Firefox.
Thoughts?
Micah
Jul 15, 2010, 4:57:37 PM7/15/10
to OpenACD
My bet is the underlying data structs that cache the queue and agent
data have some leaks. I'll run some tests and see if my hunch is
correct.
Micah
data have some leaks. I'll run some tests and see if my hunch is
correct.
Micah
Melcon Moraes
Jul 16, 2010, 1:44:09 PM7/16/10
to ope...@googlegroups.com
I'm curious, what are you using for the load test?
-
MM
Douglas Hubler
Jul 16, 2010, 1:51:50 PM7/16/10
to ope...@googlegroups.com
On Thu, Jul 15, 2010 at 3:17 PM, Jerry Browne <jerryb...@gmail.com> wrote:
> During these load tests we consistently have the Agent UI go
> unresponsive when we are viewing the Dashboard. When you first load
> it up, it seems like it does pretty well. However, over time it gets
> less and less responsive until ultimately you have to kill the process
> since it's completely locked up.
> During these load tests we consistently have the Agent UI go
> unresponsive when we are viewing the Dashboard. When you first load
> it up, it seems like it does pretty well. However, over time it gets
> less and less responsive until ultimately you have to kill the process
> since it's completely locked up.
how possible is it that this causes the load on the openacd itself as
well? or do these issues happen independently?
Jerry Browne
Jul 18, 2010, 9:45:04 PM7/18/10
to OpenACD
We have a product called WinSIP that we are using for this load
testing.
It's produced by a company called Touchstone Technologies Inc. We've
had pretty good success with the product and it's relatively
inexpensive
in the bulk call generator world ... albeit far from free.
On Jul 16, 1:44 pm, Melcon Moraes <mel...@gmail.com> wrote:
> I'm curious, what are you using for the load test?
>
> -
> MM
>
testing.
It's produced by a company called Touchstone Technologies Inc. We've
had pretty good success with the product and it's relatively
inexpensive
in the bulk call generator world ... albeit far from free.
On Jul 16, 1:44 pm, Melcon Moraes <mel...@gmail.com> wrote:
> I'm curious, what are you using for the load test?
>
> -
> MM
>
Jerry Browne
Jul 18, 2010, 9:46:22 PM7/18/10
to OpenACD
Yes, I have the same thought. Andrew, Micah, what do you guys think?
Is it
possible that the agent UI could negatively effect the OpenACD system
as a
whole?
On Jul 16, 1:51 pm, Douglas Hubler <doug...@hubler.us> wrote:
Is it
possible that the agent UI could negatively effect the OpenACD system
as a
whole?
On Jul 16, 1:51 pm, Douglas Hubler <doug...@hubler.us> wrote:
Micah
Jul 21, 2010, 2:16:10 PM7/21/10
to OpenACD
I can't discard the possibility. When the dashboard is loaded, the
agent process subscribes to the cpx_monitor. Each the cpx_monitor
gets an event, it goes through it's subscription list, and has to call
a function which determines if the event should be sent to that
subscriber. In the case of the dashboard, it always returns true.
Once the agent_web_connection gets the event, it creates a new json
object and puts it in the poll queue.
What you are describing in this thread specifically seems to be an
issue with the ui, since you are able to kill processes from the erl
prompt.
Micah
agent process subscribes to the cpx_monitor. Each the cpx_monitor
gets an event, it goes through it's subscription list, and has to call
a function which determines if the event should be sent to that
subscriber. In the case of the dashboard, it always returns true.
Once the agent_web_connection gets the event, it creates a new json
object and puts it in the poll queue.
What you are describing in this thread specifically seems to be an
issue with the ui, since you are able to kill processes from the erl
prompt.
Micah
Micah
Jul 21, 2010, 3:27:46 PM7/21/10
to OpenACD
I've tried to replicate the issue, but after 15 min of running the
dummy_callcenter with 100 agents and at minimum 30 calls in queue, the
ui was still working. How long before it becomes an issue? Does it
only seem to manifest if you are using media'ed (freeswitch) channels?
Micah
dummy_callcenter with 100 agents and at minimum 30 calls in queue, the
ui was still working. How long before it becomes an issue? Does it
only seem to manifest if you are using media'ed (freeswitch) channels?
Micah
Jerry Browne
Jul 21, 2010, 8:03:08 PM7/21/10
to OpenACD
You probably should have seen it within 15 minutes. I'd say that it
always seemed to happen within 30 minutes but it seems like much
sooner was the norm. I haven't run a load that didn't have media'd
freeswitch channels so I can't really say if it doesn't happen without
that specific config.
always seemed to happen within 30 minutes but it seems like much
sooner was the norm. I haven't run a load that didn't have media'd
freeswitch channels so I can't really say if it doesn't happen without
that specific config.
Reply all
Reply to author
Forward
0 new messages