"rbilderback" wrote:

Grettings all, hopefully someone has seen this before and can offer some assistance.

I have a primary zenoss server and a remote collector.

When browsing to the "Status" or "OS" tab of the remotely collected device, the website is very slow. Maybe 2-3 minutes to pull up the webpage.

All other devices (collected on the primary) are fast.
All other tabs (Events, Edit, Perf, Hardware, Software) for the remotely collected devices are fast.
Pulling up a specific interface (once you do get to the OS tab) is fast.
Graphs come from the remote collector are returned in a second or two.

I do have a low bandwidth, high (40ms) latency, connection between the 2 hosts.

I don't think it's an issue on either server -- load, cpu, memory, disk all look good.

I don't know if it's a zenoss problem, or a network problem. Or a combination. I don't think it is network because a TCPDUMP on the 2 hosts (and to the device being collected) does not seem to show alot of traffic.

Servers are quad-core with 8GB ram each, SAS disks. The primary collects about 1400 devices, the remote collects about 50 for now, with plans to collect maybe another 200.

If you have any pointers of where I should look, please let me know.

Thanks again for any insight.

--Randy

Grettings all, hopefully someone has seen this before and can offer
some assistance.

I have a primary zenoss server and a remote collector.

When browsing to the "Status" or "OS" tab of the remotely collected
device, the website is very slow. Maybe 2-3 minutes to pull up the
webpage.

All other devices (collected on the primary) are fast.
All other tabs (Events, Edit, Perf, Hardware, Software) for the
remotely collected devices are fast.
Pulling up a specific interface (once you do get to the OS tab) is
fast.
Graphs come from the remote collector are returned in a second or two.

I do have a low bandwidth, high (40ms) latency, connection between
the 2 hosts.

I don't think it's an issue on either server -- load, cpu, memory,
disk all look good.

I don't know if it's a zenoss problem, or a network problem. Or a
combination. I don't think it is network because a TCPDUMP on the 2
hosts (and to the device being collected) does not seem to show alot
of traffic.

Servers are quad-core with 8GB ram each, SAS disks. The primary
collects about 1400 devices, the remote collects about 50 for now,
with plans to collect maybe another 200.

If you have any pointers of where I should look, please let me know.

Thanks again for any insight.

I have both zopectl and zenrender running on the collector--I though
I needed them both to serve graphs to the user's workstation (via
the URL in the performance page).

Your assessment seems like that would be the right direction to
pursue. I am a newbie with zenoss. Is there a way I can test XML-
RPC independent of the zenoss app / user itnerface? I'll start
checking now...

I've setup in the collector config (on the primary server) with a
RenderServer URL of http://dvr.zenoss.SUB.DOMAIN:8080/zport/RenderServer

Primary server is http://zenoss.SUB.DOMAIN:8080

Knowing to look for an XMLRPC issue helped me find the problem with
the slow UI.

The RenderURL seems to be used for two things. I had NAT issues.
The users browser is on the LAN (think public) and the 2 zenoss
servers are in an OBM network (think private).

The RenderURL is used for two things:
-- the user (LAN/Public) needs it to see the graph on the remoete
-- the main server needs it for RPC to the remote

I fixed it by setting up a DNS entry in the LAN for the workstations/
web browsers. And putting the private IP address in the hosts file
on the main server. So the main server accesses it via private IP.

I tried setting the RenderURL back to the main server and shutting
down Zope on the collector, but now luck. I assumed by
"collectorID" you meant the host-name of the collector. If that was
an incorrect assumption, please advise.

Thanks again for your guidance. 90% of the problem is solved :)