Nmap Development mailing list archives

Tudor's Status Report - #12 of 17


From: Tudor-Emil COMAN <tudor_emil.coman () cti pub ro>
Date: Tue, 19 Jul 2016 05:15:31 +0000

Hello,


This week I used valgrind for profiling with it's callgrind tool. It's a lot better than gprof because it doesn't have 
the problem of having a low sample rate and not catching calls that don't last much but that happen a lot.


So far I tried to see what can be improved in ultra_scan and there I found one big performance issue.

For a scan that uses a huge number of probes, identifying the right probe that corresponds to a received package 
iterates through all the outgoing probes (which can be a lot), for each probe you have to get it's sockaddr_storage by 
calling memcpy.

For a scan like: /nmap 45.33.49.119/24 -Pn -n -sS --min-rate 50000 &> /dev/null -o log2


Callgrind shows that 11% of the scan is spent just calling memcpy before you compare the addresses of the received 
package and the outgoing probes.

It is possible to avoid calling memcpy if we made a Target::CompareSockAddr() thus improving the scan by 11%


Also for a large number of probes, reusing the memory that was allocated for a completed probe could improve this 
particular scan by about 2%.



Accomplishments:

- Made the CONCURRENCY_LIMIT in NSE the maximum between 1000 ( the previous value) and the value you pass with the 
--min-parallelism parameter.

- Found and fixed a performance bottleneck.



Priorities:

- Use callgrind on scans with more hosts, service scans and OS detection scans.

- Solve the performance bottlenecks I find.

- Commit my changes to SVN


Cheers,

Tudor


_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

Current thread: