Fiddler performance tweaks

[Andrew]

Hi there,

Does anyone have a set of suggested performance tweaks for Fiddler (not Fiddler Core) so it parses, decrypts, and particularly AutoResponds as efficiently as possible?

I know about 

(1) "Stream"

(2) "Keep: xxx sessions" (to reduce memory pressure)

(3) Don't "Parse websocket messages"

(4) Run Fiddler at AboveNormal priority 

(5) "Don't decrypt draffic for the following hosts" (if applicable to your situation)

I guess I'm looking for absolutely any optimization trick I may be missing. 

Are there, perhaps, hidden registry settings for the number of worker threads Fiddler spins up to do it's processing? Or something else entirely I am neglecting.

Thanks for any assistance!

Andrew

[Eric Lawrence]

It'd be useful to understand what performance problems you're encountering (and specifically where) and what sorts of numbers you're seeing.

Your FiddlerScript can call oSession.Ignore() on Sessions that are not of interest to avoid processing them to the extent possible.

The !threads QuickExec command enables you to pre-size the thread pool to a larger fixed size if that's of interest to you; this is relevant in some scenarios as the .NET thread pool growth algorithm grows an exhausted pool by no more than 2 threads per second.

[Andrew]

Hi Eric,

I am not experiencing any specific issues yet - I am being paranoid. I am expecting something like a 43% increase in load on several Fiddler servers.

I was able to simulate an increased load with Ctrl+R - highlight dozens of sessions, and watch Fiddler get bogged down with the load (99% CPU utilization, "Not Responding" - etc). That was at AboveNormal priority; nothing else running on the server.

I am in the unfortunate position where Fiddler is going to become a production server to serve a certain number of requests to clients. 

Thanks for the thread pool tip, that is great. 

[Andrea]

Hi Eric,

Does the order of the AutoResponder rule impact performance? I.e. if I have 500 rules, is it beneficial for a frequently accessed rule to be at the top of the list?

(I'm trying to imagine the AutoResponder code and suspect this may be the case)

[Eric Lawrence]

Yes, it impacts both performance and functionality (as one request could match multiple rules); the first "final" rule ends its processing.

If all of your rules are scoped to, for instance, one host, you could put a NOT: rule first with an *exit action.

Having said that, string compares are fast and even regex rules aren't too bad.