[SERVER-30195] Increase connection pool timeout for administrative pools Created: 17/Jul/17  Updated: 08/Jan/24  Resolved: 17/Aug/18

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

Type: Improvement Priority: Major - P3
Reporter: Mira Carey Assignee: Mira Carey
Resolution: Won't Fix Votes: 5
Labels: former-quick-wins, neweng, service_architecture
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-30643 Performance regression with SSL Closed
is related to SERVER-36734 Provide sane TaskExecutor's for admin... Open
Participants:
Case:

 Description   

The network interface's in administrative pools should have substantially longer connection timeouts than the default, due to sharing of pools with very intermittent use.

I believe the interesting set to be:

  • ReplicaSetMonitor-TaskExecutor
  • ShardRegistryUpdater
  • NetworkInterfaceASIO-ShardRegistry
  • AddShard-TaskExecutor
  • NetworkInterfaceASIO-Replication
  • NetworkInterfaceASIO-RS
  • NetworkInterfaceCollectionRangeDeleter-TaskExecutor


 Comments   
Comment by Mira Carey [ 17/Aug/18 ]

Closing this as wont fix, as I think the better long term solution is to re-architect the excessive number of TaskExecutors into a smaller set which share networking and use an unlimited ThreadPool backend.

Comment by Andy Schwerin [ 18/Jul/17 ]

So that's 2 pools for replication (NetworkInterfaceASIO-Replication and NetworkInterfaeASIO-RS), and 5 for sharding (the rest). The two instances in replication should ultimately be combined, now that they're both instances of ThreadPoolTaskExecutor (as of SERVER-28865).

Interestingly, none of the sharding executors except the AddShard one actually use the asio networking. They use TaskExecutor for work scheduling. AddShard's executor is only used for contacting replica sets that aren't yet in a sharded cluster to bring them into the fold, so can't be affecting steady state performance.

Generated at Thu Feb 08 04:22:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.