refactor: Migrate to folly::available_concurrency

[yfeldblum]

Summary: The name hardware_concurrency, while parallel to std::thread::hardware_concurrency, may be misleading. Migrate to the name available_concurrency.

Differential Revision: D96480646

Summary by Sourcery

Migrate Presto server concurrency configuration and related tests from folly::hardware_concurrency to folly::available_concurrency for determining core-based thread counts and limits.

Enhancements:

• Use folly::available_concurrency for sizing server thread pools, connector executors, and overload thresholds instead of folly::hardware_concurrency.

Tests:

• Update server and config tests to assert against folly::available_concurrency so they reflect the new concurrency source.

== NO RELEASE NOTE ==

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Refactors Presto server configuration and tests to use folly::available_concurrency instead of folly::hardware_concurrency wherever CPU/thread-capacity is derived, keeping behavior but aligning naming with Folly’s available concurrency concept.

Flow diagram for thread pool sizing with folly_available_concurrency

flowchart TD
  A[Start PrestoServer_initializeThreadPools] --> B[Call folly_available_concurrency]
  B --> C[Store result in hwConcurrency]

  C --> D[Read SystemConfig_exchangeHttpClientNumIoThreadsHwMultiplier]
  D --> E["Compute numExchangeHttpClientIoThreads = max(multiplier * folly_available_concurrency, 1)"]
  E --> F[Create folly_IOThreadPoolExecutor for exchangeHttpIoExecutor_]

  C --> G[Read SystemConfig_exchangeHttpClientNumCpuThreadsHwMultiplier]
  G --> H["Compute numExchangeHttpClientCpuThreads = max(multiplier * folly_available_concurrency, 1)"]
  H --> I[Create folly_CPUThreadPoolExecutor for exchangeHttpCpuExecutor_]

  C --> J[Read SystemConfig_connectorNumCpuThreadsHwMultiplier]
  J --> K["Compute numConnectorCpuThreads = max(multiplier * folly_available_concurrency, 0)"]
  K --> L{numConnectorCpuThreads > 0?}
  L -- Yes --> M[Create folly_CPUThreadPoolExecutor for connectorCpuExecutor_]
  L -- No --> N[Skip CPU connector executor]

  C --> O[Read SystemConfig_connectorNumIoThreadsHwMultiplier]
  O --> P["Compute numConnectorIoThreads = max(multiplier * folly_available_concurrency, 0)"]
  P --> Q{numConnectorIoThreads > 0?}
  Q -- Yes --> R[Create folly_IOThreadPoolExecutor for connectorIoExecutor_]
  Q -- No --> S[Skip IO connector executor]

  M --> T[Finish PrestoServer_initializeThreadPools]
  N --> T
  R --> T
  S --> T

  subgraph Overload_check_and_status_reporting
    U[PrestoServer_checkOverload] --> V[static hwConcurrency = folly_available_concurrency]
    V --> W["Compute overloadedThresholdQueuedDrivers = hwConcurrency * workerOverloadedThresholdQueuedMultiplier"]

    X[PrestoServer_fetchNodeStatus] --> Y[Call folly_available_concurrency]
    Y --> Z[Include availableConcurrency in NodeStatus]
  end

Loading

File-Level Changes

Change	Details	Files
Replace all uses of folly::hardware_concurrency with folly::available_concurrency across server initialization, config helpers, and tests.	In PrestoServer::initializeThreadPools, use available_concurrency to size driver, exchange HTTP IO, and CPU thread pools based on system-config multipliers instead of hardware_concurrency. In PrestoServer::checkOverload and fetchNodeStatus, compute overload thresholds and node status CPU capacity using available_concurrency rather than hardware_concurrency. In Configs::hardwareConcurrency helper, call available_concurrency and adjust the safety comment while keeping the GT(0) invariant, so executors still rely on a positive concurrency value. Update system and query config endpoint tests to expect values based on available_concurrency, keeping them in sync with the runtime behavior. Update thread-pool-based trace replayer tests to construct CPUThreadPoolExecutor with available_concurrency so test behavior matches the new concurrency naming and source.	presto-native-execution/presto_cpp/main/PrestoServer.cpp presto-native-execution/presto_cpp/main/common/Configs.cpp presto-native-execution/presto_cpp/main/tests/ServerOperationTest.cpp presto-native-execution/presto_cpp/main/common/tests/ConfigTest.cpp presto-native-execution/presto_cpp/main/tool/trace/tests/BroadcastWriteReplayerTest.cpp presto-native-execution/presto_cpp/main/tool/trace/tests/PartitionAndSerializeReplayerTest.cpp

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• The helper hardwareConcurrency() in Configs.cpp now wraps folly::available_concurrency(), which is confusingly named; consider renaming it (and any related identifiers) to reflect the new underlying API.
• In PrestoServer::initializeThreadPools, some thread counts directly call folly::available_concurrency() while others use the cached hwConcurrency value; consider using a single cached value consistently (and renaming it) to avoid repeated calls and improve clarity.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The helper `hardwareConcurrency()` in `Configs.cpp` now wraps `folly::available_concurrency()`, which is confusingly named; consider renaming it (and any related identifiers) to reflect the new underlying API.
- In `PrestoServer::initializeThreadPools`, some thread counts directly call `folly::available_concurrency()` while others use the cached `hwConcurrency` value; consider using a single cached value consistently (and renaming it) to avoid repeated calls and improve clarity.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[steveburnett]

Please add a release note following the Release Notes Guidelines to pass the failing but not required CI check.

Please edit the PR title to follow semantic commit style to pass the failing and required CI check. See the failure in the test for advice.
If you can't edit the PR title, let us know and we can help.

[yfeldblum]

@steveburnett Thanks for looking. Should be done.

[aditi-pandit]

Thanks @yfeldblum

Posting this AI analysis for others to understand this change

1. Folly::hardware_concurrency()
   This function provides the maximum theoretical parallelism supported by the CPU hardware. If you have a 20-core machine with hyperthreading enabled, this will likely return 40. However, if you run to restrict your program to a single core, this function still returns 40, which can lead to oversubscription if you spawn 40 threads. [1, 4]

2. Folly::available_concurrency()
   This function is designed to prevent performance degradation due to oversubscription in shared environments. It inspects the process's current CPU affinity and container settings.
   Example: On a 20-core machine, if a cgroup restricts the process to 4 cores, will return 4, whereas will return 20.

Recommendation: For optimal performance, especially when using thread pools, available_concurrency is generally preferred as it adapts to the actual, restricted capacity of the environment. [1]

@majetideepak @czentgr