[SERVER-43065] Perf Tests Needed For Deprecation of legacy wire protocol Created: 28/Aug/19  Updated: 06/Dec/22  Resolved: 24/Feb/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Lauren Lewis (Inactive) Assignee: Backlog - Service Architecture
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Service Arch
Participants:

 Description   

tl;dr: with some performance tests we can see if we can deprecate OP_QUERY and OP_GETMORE in favor of find and getMore. OP_QUERY and OP_GETMORE are legacy for FCV 3.2 servers and drivers.

 

Charlie Swanson wrote in PM-1371:

I believe there was some noticeable regression of the find and getMore commands compared to OP_QUERY and OP_GETMORE?

 

I asked for more and he wrote:

The summary is that the query team would love to deprecate the legacy wire protocol and move on to find and getMore commands for everything. Our understanding is that the command versions are the default in modern drivers, but no one is comfortable deprecating the old ones because there was some performance regression when first testing find and getMore command vs. the old OP_QUERY and OP_GETMORE. I have heard rumors that further investigation proved the server wasn't as much to blame as we thought it was, but we haven't followed up to build new performance tests and validate that performance is comparable. Supporting OP_QUERY and OP_GETMORE has slowed development of many query projects. The most recent example I can think of is change streams. We currently have two implementations for iterating a cursor: OP_GETMORE and getMore command are completely independent and definitely duplicate a lot of logic. We have postponed investing in refactoring this in hopes of deprecating OP_GETMORE. See SERVER-24478.

 



 Comments   
Comment by Lauren Lewis (Inactive) [ 24/Feb/22 ]

We haven’t heard back from you for at least one calendar year, so this issue is being closed. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Comment by Sheeri Cabral (Inactive) [ 29/Aug/19 ]

Assigning to service architecture backlog, although there's also drivers work to be done (but that's in a separate ticket). It's possible that the perf tests are the responsibility of drivers, too? Will cc Scott.

Comment by Sheeri Cabral (Inactive) [ 29/Aug/19 ]

 
Sheeri: This is great information. What kind of user impact does this have, to deprecate OP_GETMORE? Is it all under the hood, or would folks on legacy drivers/clients have to upgrade/change code?
 
 
Charlie: Good question. I think the folks on drivers would have a better answer, but my suspicion is that it would require either upgrading the driver or changing the code which configures the driver. Not "free", but I would hope it's relatively non-invasive.
 
David Storch weighed in:
 Anyone who is using a 3.2 or newer driver without special configuration against a 3.2 or newer server is using the find/getMore commands, and will not be using OP_QUERY/OP_GETMORE. Such users would be unaffected by deprecating the legacy reads protocol. Applications using older drivers can simply upgrade their drivers in order to ensure that they are not using legacy reads.
 
There are a few subtleties with this:

  • Drivers like to support really old versions of the server, and thus will probably continue to maintain support for OP_QUERY/OP_GETMORE in order to communicate with an old server. Deprecation and eventual removal would help server team a lot, but would take longer to simplify the lives of driver engineers.
  • I'm not sure about this, but some drivers may have a configuration option to allow using legacy reads against a 3.2 or newer server. We would need to determine whether or not this is the case, and if so, how many applications rely on it.
  • As Charlie alluded to, it's possible that the server and/or drivers may still be slower for read commands than for legacy reads. In order to be comfortable with this deprecation, we may wish to schedule a performance investigation to get up-to-date numbers.
  • It's possible that drivers still fall back to OP_QUERY/OP_GETMORE for some exotic options, e.g. exhaust cursors. We should check with them.

This spec may be helpful in describing how drivers use the read commands, although I'm not sure if it's fully up to date.

Generated at Thu Feb 08 05:02:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.