Production postmortemThe case of the man in the middle

time to read 3 min | 553 words

One of the most frustrating things when you dealing with production issues is when the problem is not in our product, but elsewhere. In particular, this post is dedicated to the hard work done by many anti virus products, in particular, to make our life harder.

Let us take a look at the following quote, taken from the ESET NOD32 Anti Virus knowledge base (emphasis mine):

By default, your ESET product automatically detects programs that are used as web browsers and email clients, and adds them to the list of programs that the internal proxy scans. This can cause loss of internet connectivity or other undesired results with applications that use network features but are not web browsers/email clients.

Yes, it can. In fact, it very often does.

Previously, we looked at a similar issue with Anti Virus slowing down I/O enough to cause us to slowly die. But in this case, the issue is a lot more subtle.

Because it is doing content filtering, it tends to put a much higher overhead on the system resources, which means that as far as the user is concerned, RavenDB is slow. We actually developed features specifically to handle this scenario. The traffic watch mode will tell you how much time you spend on the server side, and we have added a feature that will make RavenDB account for the internal work each query is doing, so we can tell where the actual cost is.

You can enable that by issuing:

GET databases/Northwind/debug/enable-query-timing

And one that is setup, you can get a good idea about what is costly in the query, as far as RavenDB is concerned. Here is an example of a very slow query:


You can see that the issue is that we are issuing a very wide range query, so most of the time is spent in inside Lucene. Other examples might be ridicilously complex queries, which result in high parsing time (we have seen queries in the hundreds of KB range). Or loading a lot of big documents, or… you get the drift. If we see that the server thinks that a query is fast, but the overall time is slow, we know to blame the network.

But an even more insidious issue is that this would drop requests,  consistently and randomly (and yes, I know that those are contradictions, it was consistently dropping requests in a random pattern that seemed explicitly designed to thwart figuring out what is going on). Leading to things breaking, and escalated support calls. “RavenDB is broken” leads to a lot of headache, and a burning desire to hit something when you figure out that not only isn’t it your fault, but the underlying reason is actively trying to prevent you from figuring it out (I assume it is to deal with viruses that try to shut it off), which lead to really complex find facting sessions.

That is more annoying because it seems that the issue there was a bug in respecting keep alive sessions for authenticated requests under some scenarios, in the AV product in question! Absolutely not fun!

More posts in "Production postmortem" series:

  1. (07 Jun 2019) Printer out of paper and the RavenDB hang
  2. (18 Feb 2019) This data corruption bug requires 3 simultaneous race conditions
  3. (25 Dec 2018) Handled errors and the curse of recursive error handling
  4. (23 Nov 2018) The ARM is killing me
  5. (22 Feb 2018) The unavailable Linux server
  6. (06 Dec 2017) data corruption, a view from INSIDE the sausage
  7. (01 Dec 2017) The random high CPU
  8. (07 Aug 2017) 30% boost with a single line change
  9. (04 Aug 2017) The case of 99.99% percentile
  10. (02 Aug 2017) The lightly loaded trashing server
  11. (23 Aug 2016) The insidious cost of managed memory
  12. (05 Feb 2016) A null reference in our abstraction
  13. (27 Jan 2016) The Razor Suicide
  14. (13 Nov 2015) The case of the “it is slow on that machine (only)”
  15. (21 Oct 2015) The case of the slow index rebuild
  16. (22 Sep 2015) The case of the Unicode Poo
  17. (03 Sep 2015) The industry at large
  18. (01 Sep 2015) The case of the lying configuration file
  19. (31 Aug 2015) The case of the memory eater and high load
  20. (14 Aug 2015) The case of the man in the middle
  21. (05 Aug 2015) Reading the errors
  22. (29 Jul 2015) The evil licensing code
  23. (23 Jul 2015) The case of the native memory leak
  24. (16 Jul 2015) The case of the intransigent new database
  25. (13 Jul 2015) The case of the hung over server
  26. (09 Jul 2015) The case of the infected cluster