--- title: gRPC performance benchmarks on GKE | daily.dev description: gRPC's performance benchmarking framework has moved from long-lived GCE VMs to GKE, using a custom Kubernetes controller built with kubebuilder to manage... canonical: https://daily.dev/posts/grpc-performance-benchmarks-on-gke-flfghbc2d twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: gRPC performance benchmarks on GKE | daily.dev og:description: gRPC's performance benchmarking framework has moved from long-lived GCE VMs to GKE, using a custom Kubernetes controller built with kubebuilder to manage... og:url: https://daily.dev/posts/grpc-performance-benchmarks-on-gke-flfghbc2d og:image: https://api.daily.dev/og/posts/FlfgHBc2d.png og:image:alt: gRPC performance benchmarks on GKE og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # gRPC performance benchmarks on GKE **[gRPC Blog](https://daily.dev/sources/grpc-blog)** · 12 min read · 0 upvotes · 0 comments ## Summary gRPC's performance benchmarking framework has moved from long-lived GCE VMs to GKE, using a custom Kubernetes controller built with kubebuilder to manage LoadTest resources. This enables parallel test execution, consistent VM state via dockerized workers, and easier ad-hoc experimentation. The post details cluster node pool configuration, continuous integration setup (running 220 tests across 8-core and 30-core pools), config generation, prebuilt worker images, a queue-based test runner, and a dashboard backed by BigQuery and Postgres. Results show similar or better latency/QPS metrics compared to the old GCE-based setup, with pod creation/deletion overhead under 15 seconds. Practical tips include using c2 instance types, enabling hostNetworking for near-native GCE network performance, and explicitly setting processor counts for Java under Docker to avoid thread pool misconfiguration. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does gRPC under Java in Docker show pessimistic benchmark results on Kubernetes? The JVM often cannot automatically detect the number of available processors inside a Docker container, and gRPC relies on that detected count to size its thread pools for processing events. When the detection fails, thread pools are undersized, leading to pessimistic latency and throughput results. The workaround is to explicitly set the number of processors for the JVM rather than relying on autodetection. _Teams tuning gRPC performance in containerized environments can find similar Java/Kubernetes gotchas on daily.dev._ ### How much overhead does GKE pod creation and deletion add to gRPC benchmark tests? Pod creation and deletion overhead in GKE benchmarking clusters is small, around 12.8 seconds per test on average and under 15 seconds overall, based on measurements from continuous integration runs executing 122 tests on an 8-core worker pool. This overhead is considered modest relative to each test's 30-second run plus warm-up period. _Engineers benchmarking Kubernetes workloads can track infrastructure overhead findings like this on daily.dev._ ### Does GKE pod-to-pod networking add overhead compared to raw GCE networking for gRPC benchmarks? GKE pod-to-pod networking adds only a very small overhead compared to raw GCE networking in gRPC benchmark testing. Raw GCE networking performance can be achieved by setting hostNetworking:true for the benchmark pods, bypassing the pod networking layer entirely. _Developers weighing GKE networking trade-offs for latency-sensitive services can follow benchmarking insights on daily.dev._ ## Similar posts on daily.dev - [How we built a 130,000-node GKE cluster](https://daily.dev/posts/how-we-built-a-130-000-node-gke-cluster-t7cc5stwb) · Hacker News · 0 upvotes · 0 comments - [GKE CPU startup boost: Faster pod starts, lower costs](https://daily.dev/posts/gke-cpu-startup-boost-faster-pod-starts-lower-costs-41twx2pz2) · Google Cloud · 0 upvotes · 0 comments - [The cluster that runs on our own metal: rebuilding survey processing on hybrid Kubernetes](https://daily.dev/posts/the-cluster-that-runs-on-our-own-metal-rebuilding-survey-processing-on-hybrid-kubernetes-4inmn4eto) · Medium · 0 upvotes · 0 comments - [How to run performance tests using benchmark-runner](https://daily.dev/posts/how-to-run-performance-tests-using-benchmark-runner-u6n5niubp) · Red Hat Developer · 2 upvotes · 0 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#grpc](https://daily.dev/tags/grpc), [#gke](https://daily.dev/tags/gke) [View this post on daily.dev](https://daily.dev/posts/grpc-performance-benchmarks-on-gke-flfghbc2d) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"gRPC performance benchmarks on GKE","url":"https://daily.dev/posts/grpc-performance-benchmarks-on-gke-flfghbc2d","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/grpc-performance-benchmarks-on-gke-flfghbc2d"},"datePublished":"2026-08-23T07:20:21.910Z","dateModified":"2026-08-23T07:22:29.862Z","description":"gRPC's performance benchmarking framework has moved from long-lived GCE VMs to GKE, using a custom Kubernetes controller built with kubebuilder to manage...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10aae04dfd3ba4523d83e4087201877a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10aae04dfd3ba4523d83e4087201877a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"gRPC Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"gRPC Blog","logo":"https://media.daily.dev/image/upload/s--asedGCAx--/f_auto,q_auto/v1787469607/logos/grpc-blog?_a=BAMAMicg0","url":"https://daily.dev/sources/grpc-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/grpc-performance-benchmarks-on-gke-flfghbc2d","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,grpc,gke","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"gRPC Blog","item":"https://daily.dev/sources/grpc-blog"},{"@type":"ListItem","position":3,"name":"gRPC performance benchmarks on GKE"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/grpc-performance-benchmarks-on-gke-flfghbc2d#faq","mainEntity":[{"@type":"Question","name":"Why does gRPC under Java in Docker show pessimistic benchmark results on Kubernetes?","acceptedAnswer":{"@type":"Answer","text":"The JVM often cannot automatically detect the number of available processors inside a Docker container, and gRPC relies on that detected count to size its thread pools for processing events. When the detection fails, thread pools are undersized, leading to pessimistic latency and throughput results. The workaround is to explicitly set the number of processors for the JVM rather than relying on autodetection. Teams tuning gRPC performance in containerized environments can find similar Java/Kubernetes gotchas on daily.dev."}},{"@type":"Question","name":"How much overhead does GKE pod creation and deletion add to gRPC benchmark tests?","acceptedAnswer":{"@type":"Answer","text":"Pod creation and deletion overhead in GKE benchmarking clusters is small, around 12.8 seconds per test on average and under 15 seconds overall, based on measurements from continuous integration runs executing 122 tests on an 8-core worker pool. This overhead is considered modest relative to each test's 30-second run plus warm-up period. Engineers benchmarking Kubernetes workloads can track infrastructure overhead findings like this on daily.dev."}},{"@type":"Question","name":"Does GKE pod-to-pod networking add overhead compared to raw GCE networking for gRPC benchmarks?","acceptedAnswer":{"@type":"Answer","text":"GKE pod-to-pod networking adds only a very small overhead compared to raw GCE networking in gRPC benchmark testing. Raw GCE networking performance can be achieved by setting hostNetworking:true for the benchmark pods, bypassing the pod networking layer entirely. Developers weighing GKE networking trade-offs for latency-sensitive services can follow benchmarking insights on daily.dev."}}]} ```