Tim Beale 630857c71e traffic_replay: Avoid DB full scans in LDAP searches ... When generating LDAP search traffic, a full DB scan can be very costly. Avoiding full-scan LDAP searches means that we can run traffic_replay against a 100K user DB and get some sane results. Because the traffic_learner doesn't record the LDAP search filter at all, the traffic_replay LDAP searches default to being full scans. Doing full scans meant that the LDAP search was usually the first packet type to exceed the max latency and fail the test. It could also skew results for the other packet types by creating big demands on memory/CPU/ DB-lock-time. It's hard to know for sure exactly what real-world LDAP searches will look like, but let's assume full scan searches will be fairly rare. In traffic-model files we've collected previously, some of the attributes are fairly unique (e.g. pKIExtendedKeyUsage), and as there are some LDAP queries specified in MS specs (such as MS-GPOL and MS-WCCE), it allows us to infer what the search filter might be. Signed-off-by: Tim Beale <timbeale@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org>		2019-07-24 02:24:27 +00:00
..
__init__.py	scripts: Scripts to replay and generate samba traffic	2017-08-17 04:06:06 +02:00
traffic_packets.py	traffic_replay: Avoid DB full scans in LDAP searches	2019-07-24 02:24:27 +00:00
traffic.py	traffic_replay: Avoid DB full scans in LDAP searches	2019-07-24 02:24:27 +00:00