引用官方的原話如下
Very cool test - thanks for sharing! 😃 We actually started out building some performance measurements a few weeks ago: https://github.com/mitmproxy/mitmproxy/tree/master/test/bench. I need to understand, am I doing something wrong on my end ? or is this an expected behaviour ? This is not expected behaviour, but may very well be an issue with our current architecture. @cortesi will probably be very interested in looking into this, he is in the process of replacing our eventloop with something asyncio-based to increase performance. If this works as planned, it should tackle exactly our problem here. For reference, the expected behaviour is as follows: For a few requests, mitmproxy, mitmdump and mitmweb should exhibit similar performance characteristics. Mitmdump is of course a bit more lightweight than its companions, so it probably beats the others by an edge. For long-running sessions, mitmproxy's and mitmweb's RAM usage will increase, whereas mitmdump forgets about connections once they are finished. 百度翻譯過來就是（ 對於一些請求，mitmproxy、mitmdump和mitmweb應該表現出類似的性能特征。當然，mitmdump比它的同伴要輕一點，所以它可能比其他人強一點。 對於長時間運行的會話，mitmproxy和mitmweb的ram使用將增加，而mitmdump在連接完成后會忘記連接。 ） Regarding your test setup: I do like that your tests are very practical, but there are many factors that can introduce noise: temporal network latencies, packet loss, HTTP edge caching, or DNS caches. If you want dependable results, I'd suggest to at least randomize test order and most importantly do multiple test runs and report on standard deviation. Please don't hesistiate to get in touch if you have further questions, we're quite interested in the results here. :-) Thanks again!
所以執行長時間的任務，適合用mitmdump，之前我用mitmweb命令，10幾個小時后，mac的占用內存就達到了23G。。。
改用mitmdump命令后，內存占用明顯下降。
另外使用-q也就是不輸出日志的靜默模式，是否能有效降低內存使用，有待測試。
mitmdump -q -p 8889 -s addons.py