[Support #VOC-356419]: latency

Michael,

> We're using Zabbix to monitor among other things, processor load on our LDM 
> server.  I can't say how the limit for the Zabbix LDM server alarm was 
> determined (calculation, experience, guess) but it is indicating that the 
> processer is overloaded.  I ran netstat and found several of our field 
> offices with process counts in the upper-teens, one in the 20's and one at 
> 83.  My guess is that those processes could be combined into much more 
> efficient and fewer processes.

If you have the top(1) utility installed, you could use it to help determine 
which processes are consuming the CPU.

> My second question was stated poorly.  I didn't mean "EXP|FSL2|FSL3" vs ".*". 
>  Instead, I should have asked, given...
> 
> EXP "(abc)|(def)|(ghi)"       ldm.crh.noaa.gov
> 
> Vs.
> 
> EXP "abc"     ldm.crh.noaa.gov
> EXP "def"     ldm.crh.noaa.gov
> EXP "ghi"     ldm.crh.noaa.gov
> 
> In terms of efficiency, is the first example better than the second?

I'm afraid there are too many variables to give a definitive answer.  Which one 
is more efficient depends, among other things, on the amount of physical 
memory, the rate at which products arrive, what kind of TCP stack you have, how 
long it takes to switch between processes, the number of CPUs, etc.  We have 
seen cases in which multiple REQUESTs are more efficient than a single request.

My advice would be to collect metrics, change the configuration, and then see 
if the metrics show any improvement.

> Of course, the amount of data being sent would have a bearing, especially if 
> abc was very small and frequent, and def and ghi were large.  It wouldn't pay 
> to bottle up a quick transfer of abc behind a large def.  In that case, a 
> separate process for abc might be a better way to configure LDM.  I could be 
> completely mistaken though.  My counterpart in the office with 83 requests 
> believes the second example is better than the first.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: VOC-356419
Department: Support LDM
Priority: Normal
Status: Closed