Howdy! Your TLS pest again
Versions: snmp4j-2.8.jar anmp4j-agent-2.6.4
So I use the sampling profiler I can see TLSTM$ServerThread.run and our.corp.package.ClientUpdateTask.run being the slowest items. That update task sends back to connected ‘clients’ using snmp.broadcast(moCollection);
Used flight recorder and got TLSTM$SocketEntry.addRegistration at 48.83% and ServerThread.processPending at 28.09%
TLSTM is transport so it definitely seems to be TCP vs TLS transport differences
org.snmp4j.transport package took up 78.8% of the samples
Seems like it’s too slow to process tasks off the ServerThread task map? Meaning: “client side” snmp.broadcast(moCollection) from ClientUpdateTask sends to Server and then that is worked off the ServerThread… so it seems like that relationship is the slow-down…
In comparison, by simply swithcing to TCP Transport, with no other code changes, we see the largest consumers in TCP has everything alot more even and transport is not even in the top 10.
So simple question: Is this a crypto overhead that should be expected, despite not seeing any of the crypto classes in the profiler samples? Or an implementation issue despite TCP working with the same slowness??
Sincere thanks as always!!