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:
- Tudor's Status Report - #12 of 17 Tudor-Emil COMAN (Jul 18)