Don't enable GCM by default, even on Java >8?

オープン
#1,867 コメント 6 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
30/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
java

調査の方向性

まず、Java TLS のデフォルトの暗号スイート設定と、Conscrypt または Bouncycastle を検出するロジックを見つけます。指定された Java 11 ランタイムと大量のリクエスト負荷で報告された比較を再現し、その後、これらのプロバイダーがない場合に GCM がデフォルトで有効になっていないこと、およびカバレッジが意図されたプロバイダーの動作を反映していることを確認します。

索引モデルが issue の本文から書いたものです。

説明

What happened?

JRE-default GCM ciphers (even on Java >8) seem to cause a lot of heap churn. This ended up contributing heavily to a Horizon performance regression with Conjure enabled (2-3 sec operation -> 15-20 sec and about 10x more GC activity; see PDS-134017).

JRE version in use (from IL): zulu11.41.23-ca-jdk11.0.8-linux_x64

Example request load, 100 requests each 5MB in size with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, tracking all allocations >100B in size:
image

Same request load, 100 5MB requests with TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, all allocations >100B:
image

Given this load seems to scale directly with network traffic, would expect this to generally cause more GCs in any server using GCM with nontrivial request or response sizes.

What did you want to happen?

Ideally, don't try to enable GCM by default if e.g. Conscrypt/Bouncycastle isn't in use.

主要言語
Java
スター
96
フォーク
95
平均マージ
8分
マージ済み PR(30日)
55

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

palantir/conjure-java-runtime のほかの issue

palantir/conjure-java-runtime の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。