M312 Response Time Degredation, Part 3 question

MongoDB University M312: Diagnostics and Debugging
#1

Hi all,
I’ve just watched the episode in question in the subject regarding slow queries.

At the beginning Norberto (The instructor) loads 10, 100, 1000 and a million records at last.

Until 1000 records, everything goes without incidents. However when he tries to filter by {$city: “Barcelona”}, he receives:

  1. 356 ms without index, full COLLSCAN
  2. Then he creates an index by $city and repeat the query, receiving 141ms (A “dramatic change” according to the video lesson, which it might be ok, less than hafl the time)
  3. Then he said that we can do better by projecting the query for only the name (“Way better” according to him) and receives 177ms!!!

So, how could that be possible? Payload was smaller but he received a full 30ms worst.

Most important, following the course he mentioned that every single query beyond 100ms is considered slow, so EVERY query shown in that lecture is way way deep into the “slow” world, with a mere million rows, which is a LOT for a local project but rather small for even a small sized company.

Is there an explanation about the lack of speed even with the index? Could it be that is just the vagrant run in a personal laptop? I have almost no experience benchmarking queries into a full dedicated server, hence my doubts.

Regards!

#2

A lot of things may influence performance. Speed of network, quantity of memory, speed of disks, … It looks like they built a data set based on what they have to make sure they hit the slow query threshold. As you hinted, vagrant on a laptop is not a production grade setup. In particular the server and the client running on the same VM cause a lot of context switch. That might explain why projecting only the required fields is slower, more context switch and no network delays. I am sure if you remove context switch and add network delay, it will be different.

1 Like
#3

Hello @steevej and @Jose_72740

I don’t understand what Norberto the instructor means by the Payload is much much smaller in executionStats when projecting only on the name. Is he talking about the verbosity of executionStats ?

In my case, when I project only on the name {name:1, _id:=0} , I have more verbose executionStats messages comparing to not projecting at all.

For the execution time, I confirm the remark of @Jose_72740 :
I have an execution time of 181ms without projection, and 230ms by projecting only on name {name:1,_id:0}

Thanks for explanation

Regards
Otmane

#4

The payload is the amount of data transferred from the server to the application.

When you project only the fields needed by the application it is faster most of the time. The server might do a little bit more work more over all it is faster because the time taken by the server is not the total time. Network transfer is also part of the equation. For small number of small documents, projection, might be less efficient because of the overhead.

One measure for one time execution is statistically insignificant.

Yes executionStats is more verbose with a projection because more steps are executed.

1 Like
#5

Thanks @steevej for this explanation

I understand now that the server will transfer less packet data to the application when projecting only on the fields needed, it is more faster, this is become more significant when querying on big data rather than small documents.

Thanks a lot !

1 Like
#6