# HikariCP ile İleri Düzey Havuz Tasarımı

> HikariCP havuz boyutu uygulama eşzamanlılığından değil veri tabanının sürdürülebilir aktif sorgu kapasitesinden türetilmelidir; büyük havuz her zaman daha yüksek throughput sağlamaz.

- Author: Muhammet Ali Köker
- Language: tr
- Canonical: https://alikoker.com.tr/hikaricp-ile-ileri-duzey-havuz-tasarimi
- Translation: https://alikoker.com.tr/en/advanced-connection-pool-design-with-hikaricp
- Published: 2026-08-03T12:00:00+03:00
- Modified: 2026-09-08T02:30:00+03:00
- Verified: 2026-09-08T02:30:00+03:00
- Type: article

## Havuz Boyutu, İstek Sayısının Kopyası Değildir

Bir uygulamada yüzlerce eşzamanlı istek bulunması, yüzlerce aktif JDBC bağlantısının gerekli olduğu anlamına gelmez. Connection pool'un görevi her isteğe kalıcı bağlantı ayırmak değil, veri tabanının sürdürülebilir eşzamanlı çalışma kapasitesini sınırlı ve yeniden kullanılabilir bağlantılarla beslemektir. Havuz gereğinden fazla büyüdüğünde bekleme uygulamadan veri tabanına taşınır; CPU, latch/lock ve I/O çekişmesi artabilir.

Bu nedenle `maximumPoolSize` yalnız uygulama thread sayısından türetilmemelidir. Sorgu hizmet süresi, veri tabanı CPU kapasitesi, aktif oturum maliyeti ve kabul edilebilir kuyruk gecikmesi birlikte ölçülmelidir. Havuz doygunluğu bir hata değil, doğru timeout ve [geri basınç](/wiki/backpressure) politikasıyla sistemin yük sınırını görünür kılan bir kontrol noktası olabilir.

HikariCP'de `maximumPoolSize` değerini yükseltmek, veritabanına kapasite eklemek değildir. Havuzun yaptığı iş bağlantı kurma maliyetini amorti etmek ve uygulamadan gelen eşzamanlılığı sınırlı sayıda fiziksel oturuma yönlendirmektir; veritabanı aynı anda yalnız belirli miktarda işi sürdürebiliyorsa daha büyük havuz beklemeyi ortadan kaldırmak yerine içeri taşır.

Bu ayrım çok sayıda `DataSource` bulunan Oracle sistemlerinde doğrudan kapasite hesabına dönüşür. Onlarca bağımsız veri kaynağının her biri ayrı bir havuz taşıyorsa toplam teorik bağlantı hakkı `maximumPoolSize` değerlerinin toplamıdır; aynı topolojinin birden fazla kopyası bu üst sınırı yeniden katlar. Bu nedenle havuz boyutunu uygulama iş parçacığı sayısından değil, Oracle oturum sınırı, RAC dağılımı, sorgu servis süresi ve kabul edilebilir kuyruk gecikmesinden türetiyorum.

Bu ayrım çok sayıda veri kaynağı bulunan sistemlerde daha belirgindir. Onlarca ayrı `DataSource` için aynı büyüklükte havuzlar tanımlandığında teorik üst sınır tek bir havuzun sınırı değil, bütün havuzların toplamıdır. Aynı veri kaynaklarının birden fazla kopyayla temsil edilmesi bu sınırı kopya sayısıyla birlikte büyütür. Uygulama trafiği başlamadan önce bile Oracle `PROCESSES`/`SESSIONS`, RAC servis dağılımı, ağ soketleri ve işletim sistemi kaynakları bu toplam bütçeyle birlikte değerlendirilmelidir.

[Bağlantı havuzu](/wiki/connection-pool) ayarlarını yüksek trafikli Java ve Oracle sistemlerinde değerlendirirken havuzu büyütmenin gecikmeyi otomatik olarak azaltmadığını, veritabanı eşzamanlılık sınırı aşıldığında bekleme ve çekişmenin yalnızca başka katmana taşındığını gözlemledim. Bu nedenle aşağıdaki yaklaşım havuz boyutunu uygulama iş parçacığı sayısından değil, veritabanının sürdürülebilir servis kapasitesinden türetiyor.

## Havuz boyutunun belirlenmesi

Havuz boyutu saatlik istek sayısından çıkarılamaz. Bir sistem saatte milyonlarca istek alırken aynı anda yalnızca birkaç bağlantıya ihtiyaç duyabilir. Belirleyici olan, bağlantının ne kadar süre işgal edildiği ve bu işgalin ne kadar eş zamanlı gerçekleştiğidir.

İlk yaklaşım [Little Yasası](/wiki/little-s-law) ile kurulabilir:

```text
L = λW
```

"L", aynı anda meşgul olması beklenen bağlantı sayısını gösterir. "λ", saniyedeki veritabanı işlemi sayısıdır. "W" ise bir işlemin bağlantıyı elinde tuttuğu ortalama süredir.

Saniyede 500 veritabanı işlemi yapan ve bağlantıyı ortalama 20 ms tutan bir sistem için ortalama eş zamanlılık şöyledir:

```text
L = 500 x 0,020 = 10
```

Bu sonuç doğrudan "maximumPoolSize=10" anlamına gelmez. Ortalama değer, ani yükleri ve uzun kuyruk kuyruğunu göstermez. P95 ve P99 işlem süreleri, sorgu dağılımı, transaction süresi ve trafik patlamaları ayrıca ölçülmelidir.

HikariCP belgeleri de büyük havuzun otomatik olarak daha yüksek performans üretmediğini vurgular. Veritabanının çekirdek, disk ve sorgu yürütme kapasitesini aşan bağlantılar çalışmak yerine kaynak bekler. Bazı yüklerde havuz küçültüldüğünde gecikmenin belirgin biçimde azalabilmesi bu nedenle şaşırtıcı değildir.

Pratik boyutlandırma şu ölçümlerle yapılır:

- Etkin bağlantı sayısının zaman dağılımı
- Boş bağlantı sayısı
- Bağlantı bekleyen iş parçacığı sayısı
- "getConnection()" bekleme süresi
- Transaction ve sorgu sürelerinin P95 ve P99 değerleri
- Oracle oturum ve işlem sınırları
- RAC düğümlerindeki servis dağılımı
- Yük artarken veritabanı CPU ve disk kuyruğunun davranışı

Havuz sürekli doluysa çözüm her zaman havuzu büyütmek değildir. Önce bağlantının neden uzun süre tutulduğu araştırılmalıdır. Yavaş SQL, geniş transaction sınırı, ağ üzerinden yapılan işlem sırasında bağlantının açık tutulması, sonuç kümesinin geç tüketilmesi ve [ORM](/wiki/object-relational-mapping) kaynaklı N+1 sorguları aynı belirtiyi üretebilir.

## Minimum bağlantı ve dinamik büyüme

"minimumIdle", boşta tutulacak asgari bağlantı sayısını belirler. "minimumIdle" belirtilmezse HikariCP varsayılan olarak bunu "maximumPoolSize" ile aynı değerde ele alır. Böylece havuz sabit boyutluya yakın davranır. HikariCP belgeleri, ani yüklerde bağlantı oluşturma gecikmesini önlemek için sabit boyutlu havuzu çoğu durumda uygun varsayılan olarak görür.

Bu tercih her sistem için doğru değildir. Çok sayıda seyrek kullanılan veri kaynağında sabit havuz ciddi bağlantı israfı oluşturur. Şemaların yalnız küçük bir bölümü aynı anda kullanılıyorsa her havuzu başlangıçta tam kapasite açmak gereksizdir. Bu tür yapılarda düşük `minimumIdle`, ölçülü `maximumPoolSize` ve kontrollü bağlantı oluşturma daha uygun olabilir.

Dinamik büyümenin bedeli ilk isteklerde bağlantı kurma gecikmesidir. Oracle bağlantısı yalnız TCP soketinin açılmasından oluşmaz. Listener yönlendirmesi, Oracle Net görüşmesi, kimlik doğrulama, oturum kurulumu ve varsa TLS veya gelişmiş güvenlik adımları tamamlanır. Yük anında birden fazla havuzun eş zamanlı büyümesi, bağlantı fırtınası oluşturabilir.

"idleTimeout" yalnızca "minimumIdle < maximumPoolSize" olduğunda anlamlıdır. Havuz, boş bağlantıları "minimumIdle" altına düşürmez. Boş bağlantının tam olarak ayarlanan milisaniyede kapatılması da garanti edilmez. Housekeeper taramasına bağlı zaman sapması bulunur.

## Zaman aşımı katmanları

HikariCP sistemlerinde tek bir zaman aşımı yoktur. Birbirinden farklı başarısızlıkları sınırlayan birkaç zaman aşımı birlikte tasarlanmalıdır.

"connectionTimeout", uygulama kodunun havuzdan bağlantı almak için ne kadar bekleyeceğini belirler. Havuz doluysa ve süre aşılırsa "SQLException" oluşur. Bu değer, kullanıcı isteğinin toplam zaman bütçesinden kısa olmalıdır. Aksi halde HTTP isteği veya üst katman işlemi sonlanmış olsa bile iş parçacığı bağlantı beklemeye devam edebilir.

"validationTimeout", bağlantının canlılığını denetlemek için ayrılan süredir. "connectionTimeout" değerinden küçük olmalıdır. Doğrulama sorgusunun veya "Connection.isValid()" çağrısının ağda uzun süre asılı kalmasını tek başına her zaman engellemez. JDBC sürücüsünün soket ve ağ zaman aşımı da yapılandırılmalıdır.

"maxLifetime", fiziksel bağlantının havuzda yaşayabileceği azami süreyi sınırlar. Bu değer veritabanı, güvenlik duvarı, NAT, yük dengeleyici veya ağ cihazlarının bağlantıyı kapatma süresinden kısa seçilir. Amaç, bağlantının dış katman tarafından sessizce öldürülmesinden önce HikariCP tarafından kontrollü biçimde yenilenmesidir.

"keepaliveTime", uzun süre kullanılmayan bağlantının ağ yolunda canlı tutulmasına yardımcı olur. "maxLifetime" değerinden küçük olmalıdır. Keepalive, aktif olarak uygulamaya verilmiş bağlantıda çalışmaz. Yalnızca havuzun denetimindeki boş bağlantılar üzerinde uygulanır.

"connectionTimeout=2000" ve "validationTimeout=1000" gibi kısa değerler, düşük gecikmeli kurum içi sistemlerde makul bir başlangıç olabilir. Ancak bu değerler ölçüm yapılmadan evrensel ayar olarak kullanılamaz. RAC düğüm geçişi, uzak ağ, yoğun listener veya güvenlik görüşmesi iki saniyeyi aşabiliyorsa uygulama gereksiz biçimde bağlantı hatası üretir.

Zaman aşımı zinciri şu sırayı korumalıdır:

JDBC sorgu zaman aşımı
< transaction zaman aşımı
< uygulama isteği zaman aşımı

Bağlantı edinme süresi de bu toplam bütçenin yalnız bir bölümünü tüketmelidir. Veritabanı çağrısı 30 saniye sürebilir durumdayken "connectionTimeout" değerini 30 saniye yapmak, aşırı yükte kuyrukların uzun süre bellekte kalmasına yol açar.

## Oracle ağ hataları ve hızlı toparlanma

HikariCP yalnız kendi denetimindeki bağlantıları yönetebilir. Uygulama bir bağlantıyı havuzdan aldıktan sonra bu bağlantı Oracle JDBC çağrısında takılırsa HikariCP işlemi zorla kurtaramaz. Ağ bölünmesi sırasında gönderilen TCP paketine yanıt gelmezse çağrı işletim sistemi zaman aşımına kadar asılı kalabilir. HikariCP'nin hızlı toparlanma belgesi, bu nedenle JDBC sürücüsü düzeyinde soket zaman aşımı tanımlanmasını gerekli görür.

Oracle JDBC tarafında bağlantı kurma ve okuma için farklı sınırlar bulunur. "CONNECT_TIMEOUT", "TRANSPORT_CONNECT_TIMEOUT", "oracle.net.CONNECT_TIMEOUT", "oracle.jdbc.ReadTimeout" ve "Connection.setNetworkTimeout()" aynı aşamayı kontrol etmez. Özelliklerin anlamı sürücü sürümüne ve bağlantı URL'sinin yapısına göre doğrulanmalıdır. Oracle, bağlantı zaman aşımının ADDRESS listelerindeki her adres veya IP için ayrı uygulanabildiğini belirtir.

RAC ve SCAN ortamında yeniden deneme ayarları daha dikkatli ele alınmalıdır. Tek bir SCAN adı birden fazla IP ve listener yoluna çözülebilir. Her adreste uzun bağlantı zaman aşımı kullanılırsa toplam başarısızlık süresi beklenenden çok daha uzun olur.

Pool katmanında kör yeniden deneme yapılmamalıdır. Transaction'ın sunucuya ulaşıp ulaşmadığı bilinmiyorsa aynı yazma işlemini tekrar çalıştırmak çift kayıt üretebilir. [Yeniden deneme](/wiki/retry) yalnızca işlemin idempotent olduğu veya transaction sonucunun güvenilir biçimde belirlenebildiği durumlarda uygulanmalıdır.

## Transaction sınırı ve bağlantı durumu

HikariCP, bağlantı geri verildiğinde belirli JDBC durumlarını sıfırlamaya çalışır. "autoCommit", "readOnly", transaction isolation, katalog ve bazı diğer durumlar bunlara dahildir. Açık transaction varsa bağlantı iade edilirken rollback uygulanabilir. Açık bırakılmış "Deyim" nesneleri de proxy katmanında izlenerek kapatılır.

Bu koruma, hatalı transaction tasarımını güvenli hale getirmez. Bağlantı yalnız SQL çalışırken elde tutulmalıdır. Transaction içinde HTTP çağrısı, dosya erişimi, yapay zeka çıkarımı veya uzun CPU işlemi yapılmamalıdır. Bu işlemler veritabanı bağlantısını kullanmasa bile havuz kapasitesini tüketir.

"spring.jpa.open-in-view=false" ayarı, web isteği boyunca [persistence context](/wiki/persistence-context) ve bağlantı kullanımının istemeden genişlemesini önlemek için önemlidir. [Transaction sınırı](/wiki/transaction-boundary) servis katmanında açıkça belirlenmelidir. Lazy yükleme gereksinimi sorgu planı, DTO projeksiyonu veya açık fetch stratejisiyle çözülmelidir.

Isolation seviyesi SQL komutuyla değiştirilmemelidir. HikariCP değişikliği ancak JDBC "Connection.setTransactionIsolation()" çağrısı üzerinden güvenilir biçimde algılayabilir. SQL ile değiştirilen isolation seviyesi bağlantı havuza döndüğünde sıfırlanmayabilir ve sonraki kullanıcıya taşabilir.

"autoCommit=false" kullanıldığında başarılı işlemde "commit", hata yolunda "rollback" açık olmalıdır. Spring transaction yönetimi bu işlemleri üstlenebilir. Aynı bağlantı üzerinde framework transaction'ı ile elle "commit()" veya "rollback()" çağrılarını karıştırmak transaction durumunu belirsizleştirir.

## Sanal iş parçacıkları sınırı

Sanal iş parçacıkları, JDBC bağlantısı bekleyen iş parçacığının platform iş parçacığını işgal etmesini azaltabilir. Veritabanı bağlantı sayısını artırmaz. On binlerce sanal iş parçacıkları aynı anda "getConnection()" çağırdığında havuz yine "maximumPoolSize" kadar bağlantı verir. Kalan çağrılar havuz kuyruğunda bekler.

Bu nedenle sanal iş parçacıkları kullanılan sistemlerde havuz, doğal bir eş zamanlılık sınırlayıcısı haline gelir. Ancak sınırsız sayıda bekleyen sanal iş parçacıkları kabul edilebilir bir geri basınç mekanizması değildir. Bekleyen görevler öbek üzerinde durum taşır, istek zaman aşımı sonrasında gereksiz iş yapabilir ve hata anında büyük bir uyanma dalgası oluşturabilir.

Üst katmanda sınırlı kuyruk, semaphore, [admission control](/wiki/admission-control) veya [load shedding](/wiki/load-shedding) gerekir. HikariCP kuyruğu son savunma hattı olmalıdır. Veritabanının kapasitesi 20 eş zamanlı transaction ise uygulamanın 20.000 görevi havuz önünde bekletmesi sistemi daha dayanıklı yapmaz.

HikariCP'nin housekeeper, connection adder ve benzeri iç görevleri platform iş parçacığı üzerinde çalışabilir. Bunları sanal iş parçacıkları'e çevirmek beklenen bir optimizasyon değildir. Asıl kazanç, uygulama isteği iş parçacıklarının bloklayan JDBC çağrıları sırasında platform iş parçacığı tüketmemesidir.

## Leak detection ve pool locking

"leakDetectionThreshold", bağlantı belirlenen süreden uzun süre uygulamada kaldığında tanı amaçlı stack trace üretir. Bu özellik bağlantıyı geri almaz, transaction'ı sonlandırmaz ve kaçağı düzeltmez. Yalnızca bağlantının nerede alındığını bildirir.

Çok düşük eşik, normal uzun transaction'ları kaçak gibi raporlar. Yoğun üretim sisteminde stack trace üretimi ve log hacmi ek maliyet doğurur. Bu nedenle 2.000 ms gibi düşük değerler tanılama sırasında yararlı olabilir, fakat sorguları birkaç saniye süren üretim sisteminde sürekli açık tutulmamalıdır. Eşik, normal P99 transaction süresinin üzerinde seçilmeli veya sorun çözüldükten sonra kapatılmalıdır.

Gerçek bağlantı kaçağında "active" bağlantı sayısı yükselir ve geri düşmez. Yavaş sorguda ise bağlantılar geç de olsa havuza döner. Bu iki durum zaman serisiyle ayrılır.

Bir iş parçacığının aynı anda birden fazla bağlantı edinmesi pool locking riski doğurur. "Tn" iş parçacığının her biri en fazla "Cm" bağlantı tutuyorsa kilitlenmeyi önlemek için verilen alt sınır şöyledir:

```text
poolSize = Tn x (Cm - 1) + 1
```

HikariCP belgeleri bu formülü açıklarken asıl çözümün havuzu büyütmek değil, aynı iş akışının birden fazla bağlantı edinmesini ortadan kaldırmak olduğunu belirtir.

## Gözlemlenebilirlik ve arıza teşhisi

HikariCP ayarı log dosyasındaki yapılandırma çıktısına bakılarak doğrulanamaz. Pool davranışı zaman serisi olarak izlenmelidir. En az şu ölçümler gerekir:

- "active"
- "idle"
- "pending"
- "max"
- bağlantı edinme süresi
- bağlantı kullanım süresi
- bağlantı oluşturma süresi
- zaman aşımı sayısı

"active=max" ve "pending>0" kalıcı hale geliyorsa pool exhaustion vardır. Veritabanı CPU'su düşükse bağlantılar uygulama katmanında gereğinden uzun tutuluyor olabilir. Veritabanı CPU'su ve disk beklemesi yüksekse havuzu büyütmek sorunu ağırlaştırabilir.

Iş parçacığı dump içinde "HikariPool.getConnection()" beklemeleri havuz kıtlığını gösterir. "OracleStatement.execute", "T4C...", "TimeoutSocketChannel.read" veya "NIOPacket" çağrılarında yığılma varsa sorun havuzdan çok Oracle yürütme veya ağ katmanındadır. "HouseKeeper", "KeepaliveTask" ve "isConnectionAlive" üzerinde yoğun bekleme görülmesi, doğrulama çağrılarının ağda geciktiğini veya çok sayıda havuzun aynı anda bakım yaptığını gösterebilir.

Tek anlık iş parçacığı dump yeterli değildir. Ardışık dump'lar, [Java Flight Recorder](/wiki/java-flight-recorder), wall-clock profiler ve Oracle [AWR](/wiki/automatic-workload-repository) veya ASH verileri aynı zaman aralığında karşılaştırılmalıdır. CPU profili yalnız çalışan kodu gösterir. JDBC soketinde bekleyen iş parçacıkları düşük CPU tükettiği için CPU profillerinde önemsiz görünebilir.

Çok sayıda "DataSource" bulunan yapılarda metrikler pool adı, şema ve servis bilgisiyle etiketlenmelidir. Etiket sayısı denetlenmezse yüksek cardinality oluşur. Her SQL metnini veya kullanıcı kimliğini metrik etiketi yapmak uygun değildir.

## Yaşam döngüsü ve yapılandırma disiplini

Spring Boot, JDBC veya JPA starter kullanıldığında HikariCP'yi varsayılan havuz olarak seçebilir. Birden fazla "DataSource" elle tanımlandığında otomatik yapılandırmanın hangi bean için çalıştığı açıkça kontrol edilmelidir. Kendi "DataSource" bean'i tanımlandığında bazı otomatik yapılandırma davranışları devre dışı kalır.

Her "HikariDataSource" uygulama kapanırken "close()" ile kapatılmalıdır. Aksi halde housekeeper iş parçacıklarıi ve fiziksel bağlantılar hot deploy veya test çalışmaları arasında sızabilir. HikariCP bu yaşam döngüsü gereksinimini açıkça belirtir.

"initializationFailTimeout", uygulamanın veritabanı erişilemezken başlatılıp başlatılmayacağını belirleyen politikanın parçasıdır. Kritik bir servis veritabanı olmadan iş yapamıyorsa fail-fast tercih edilebilir. Birden fazla bağımsız veri kaynağı bulunan sistemde tek şemanın erişilememesi bütün uygulamayı durdurmamalıysa havuzların yaşam döngüsü ayrı yönetilebilir. Bu karar teknik bir varsayılan değil, servis sözleşmesidir.

HikariCP "PreparedStatement" önbelleğini havuz katmanında tutmaz. Önbellek gerekiyorsa JDBC sürücüsünün bağlantı başına veya sunucu tarafındaki mekanizması kullanılmalıdır. Havuz katmanında genel deyim önbellek, aynı SQL'in her bağlantı için ayrı yürütme durumu taşıması nedeniyle beklenmedik bellek maliyeti oluşturabilir. HikariCP belgeleri de hazırlanan ifade önbelleğini sürücüye bırakır.

HikariCP'nin düşük gecikmesi "ConcurrentBag", hızlı erişim yolları, proxy nesneleri ve [JIT](/wiki/just-in-time-compilation) dostu kod yapısı gibi iç optimizasyonlardan gelir. Proje, bazı sıcak metotları JIT inline sınırlarında tutmak için bytecode düzeyinde düzenlemeler yaptığını açıklar. Bu ayrıntılar havuz ayarı değildir. Uygulamadaki yavaş SQL'i veya yanlış transaction sınırını telafi etmez.

HikariCP için doğru üretim yaklaşımı birkaç sabit ayarı kopyalamak değildir. Havuz sayısı, bağlantı üst sınırı, Oracle oturum kapasitesi, transaction süresi, ağ zaman aşımı ve üst katman eş zamanlılığı birlikte modellenmelidir. "maximumPoolSize=10", "minimumIdle=2", "connectionTimeout=2000", "validationTimeout=1000" ve "autoCommit=false" bazı sistemlerde iyi bir başlangıç noktası olabilir. Bu değerler ancak yük testi, soak testi ve üretim metrikleriyle doğrulandığında gerçek bir yapılandırmaya dönüşür.

İyi ayarlanmış havuz doygunluğu gizlemez. Bağlantı bekleme süresini sınırlar, veritabanının kaldırabileceğinden fazla eşzamanlı işi içeri almaz ve arıza anında isteğin nerede beklediğini görünür bırakır. HikariCP'nin değeri, bağlantı sayısını büyütmekten çok bu sınırı düşük ek yükle uygulamasıdır.

## VTYS ile ilişki

Connection pool kapasitesi uygulama ile veritabanı arasındaki eşzamanlılık sınırıdır. Genel transaction, veri bütünlüğü ve sorgu modeli için [Veri Tabanı Sistemleri ve Veri İşleme](/vtys), Java/Oracle tarafındaki üretim davranışı için bu yazı birlikte okunabilir.

## Yönlendirme Katmanıyla İlişkisi

Birden fazla havuzun nasıl seçildiği ile havuzların ne kadar büyük olması gerektiği farklı problemlerdir. `AbstractRoutingDataSource` sınırını [HikariCP ile Dinamik Veri Kaynağı Yönlendirme](/hikaricp-ile-dinamik-veri-kaynagi-yonlendirme) notunda; toplam fiziksel oturum bütçesini bu sayfada ele alıyorum.

## Havuz Boyutu Bir Kapasite Tahmini Değil, Bir Kuyruk Kararıdır

Connection pool büyütmek çoğu zaman daha fazla paralellik sağlıyormuş gibi görünür. Oysa veri tabanının aynı anda verimli işleyebileceği iş miktarı sabitse daha büyük havuz yalnız beklemeyi uygulama katmanından veri tabanına taşır. Bu nedenle havuz boyutu thread sayısından değil, servis süresi, eşzamanlı sorgu kapasitesi ve kabul edilebilir kuyruk gecikmesinden türetilmelidir.

[Connection Pool Exhaustion](/wiki/connection-pool-exhaustion), [Queueing Delay](/wiki/queueing-delay) ve [Service Time](/wiki/service-time) bu davranışı ayrı metriklere böler. Kritik sistemlerde özellikle P50'nin iyi görünmesi yeterli değildir; doygunluk başladığında P99 ve timeout dağılımının nasıl değiştiği daha açıklayıcıdır.

## Kaynakça

- Brett Wooldridge et al. (n.d.). HikariCP - High-performance JDBC connection pool. HikariCP project. [URL](https://github.com/brettwooldridge/HikariCP)

- John D. C. Little. (1961). A Proof for the Queuing Formula: L = λW. Operations Research, 9(3), 383-387. [doi:10.1287/opre.9.3.383](https://doi.org/10.1287/opre.9.3.383)

- Ron Pressler; Alan Bateman. (2023). JEP 444: [Virtual Threads](/wiki/virtual-thread). OpenJDK. [URL](https://openjdk.org/jeps/444)

## Bu Çalışmaya Atıf

Köker, M. A. (2026). HikariCP ile İleri Düzey Havuz Tasarımı. alikoker.com.tr. https://alikoker.com.tr/hikaricp-ile-ileri-duzey-havuz-tasarimi

- BibTeX: https://alikoker.com.tr/hikaricp-ile-ileri-duzey-havuz-tasarimi.bib
- RIS: https://alikoker.com.tr/hikaricp-ile-ileri-duzey-havuz-tasarimi.ris
- CSL-JSON: https://alikoker.com.tr/hikaricp-ile-ileri-duzey-havuz-tasarimi.csl.json