Hi Jeff,
I would expect the best result with asynchronous request handling and
a MultiThreadedMessageDispatcher. The latter is important, if you
response processing blocks (= takes some time).
While the receiving thread provides the response to your code, it cannot
process further messages to other listeners. Thus, a multi-thread dispatcher
can decouple this and increase the throughput.
Hope this helps.
Best regards,
Frank
Am 04.06.2013 23:09, schrieb Jeff Pople:
Hi Frank,
I'm struggling with a performance issue when querying large numbers of devices
from a single process.
If, for example, I simultaneously issue 20 separate 'get' requests to each of
100 different addresses and repeatedly do that on a half minute cycle, I see
the CPU usage of my process plateau at a high level. If I increase the number
of devices, I don't see much more of an increase in CPU but the time taken to
fulfill each request increases on a roughly linear scale in relation to the
number of devices/requests.
I have tried using more than one Snmp instance with (as I expected) no obvious
benefit and I have tried asynchronous requests (where I can reduce CPU load by
introducing a wait for a response but this comes at the expense of overall
response times for a given set of 'gets').
Is it that ultimately all the responses to my many 'get' requests must arrive
at a single port (161) on my network interface and that the Snmp reading thread
can only process them so fast? Is there something I can do to increase
throughput short of bulking up my queries?
Any help appreciated.
Thanks
Jp
From: snmp4j-requ...@agentpp.org snmp4j-requ...@agentpp.org
To: snmp4j@agentpp.org
Sent: Monday, 3 June 2013, 20:43
Subject: SNMP4J Digest, Vol 111, Issue 3
Send SNMP4J mailing list submissions to
snmp4j@agentpp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.agentpp.org/mailman/listinfo/snmp4j
or, via email, send a message with subject or body 'help' to
snmp4j-requ...@agentpp.org
You can reach the person managing the list at
snmp4j-ow...@agentpp.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of SNMP4J digest...
Today's Topics:
1. Re: Performance hotspot in Cipher.getInstance() method call
(Praveen Jain)
2. Re: V3 Not In Time Window and Client Clock Drift (Elise Atkins)
3. Re: V3 Not In Time Window and Client Clock Drift (Frank Fock)
4. Re: V3 Not In Time Window and Client Clock Drift (Elise Atkins)
--
Message: 1
Date: Mon, 3 Jun 2013 18:24:19 +0530
From: Praveen Jain praveen.j...@esq.com
To: 'Frank Fock' f...@agentpp.com, snmp4j@agentpp.org
Subject: Re: [SNMP4J] Performance hotspot in Cipher.getInstance()
method call
Message-ID: 000501ce6059$79227420$6b675c60$@esq.com
Content-Type: text/plain;charset=us-ascii
Hi Frank,
Thanks a lot for quick reply. I would really appreciate if you backport the
fix into 1.x branch. Please let me know if there is a place where I can
track that (any issue tracking system). In case the backporting idea is
dropped for 1.x branch, please provide a patch so that I can apply the same
on source code. Thanks.
Regards,
Praveen.
-Original Message-
From: snmp4j-boun...@agentpp.org [mailto:snmp4j-boun...@agentpp.org] On
Behalf Of Frank Fock
Sent: Monday, June 03, 2013 2:59 AM
To: snmp4j@agentpp.org
Subject: Re: [SNMP4J] Performance hotspot in Cipher.getInstance() method
call
Hi Praveen,
SNMP4J is not caching the cipher object. Apparently, the performance
overhead of retrieving a Cipher instance is not that great with newer Java
versions.
Nevertheless, I am currently working on a caching solution, which does not
introduce a new bootleneek for multi-threaded usage for SNMP4J 2.x.
If it will possible, I will also provide a backport to the 1.x branch.
Best regards,
Frank
Am 30.05.2013 13:03, schrieb Praveen Jain:
We are using SNMP4J version 1.11.4 for a legacy application running in
Java
1.4 environment. The application behaved slower than expected and
profiling showed that there is hotspot in PrivDES.encrypt() method.
This method in turn calls javax.crypto.Cipher.getInstance(String)
method (apparently on each message transmission) and
Cipher.getInstance(String) is the expensive and CPU intensive call. Can
you please suggest if:
1. This might be due wrong way of calling SNMP4J api (and also point
to a reference code for correct usage to prevent this problem)
2. Is this an inherent problem with Java 1.4 code?
3. Is this a problem with SNMP 1.11.4 code (it is not caching the
obtained cipher object)?
Thanks in advance for the help.
-Praveen
___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257
