はじめに
ACS（IBM Access Client Solutions）の最大セッション数が気になったので調べてみました。
※IBM社の公式の情報ではありませんのでご注意ください。
理論値
デフォルトの仕様ではACSのセッションにはAから順にアルファベットが振られていきます。
そして、さまざまな情報から整理すると、Zに達して終わりではなく、
A、B、C、 、 、 、 、 Z、a、b、c、 、 、 、 、 z、AA、AB、AC、 、 、 、 、 AZ、BA、BB、BC、 、 、 、 、BZ、CA、CB、CC、 、 、 、 、
と続いていき、最後はZZで終わるのが仕様のようです。
この理論でいくと、セッション数としては
A-Z：26セッション
a-z：26セッション
AA-AZ：26セッション
BA-BZ：26セッション
・・・
ZAーZZ：26セッション
となり、合計で728セッションになる計算です。
（A-Zとa-zが26セッションx2、AA-ZZで26セッションx26）
ただし、ACSはJavaで動いており、この728というセッション数に達する前にハードウェアのリソースやJavaのリソースの側限界が先に来るのではないかと推測されます。
検証
728セッションも実運用することはないと思いますが、実際にどの程度までセッションが同時に利用できるのか、簡単に検証してみました。
検証方法
検証にはIBM CloudのVPCのVSIを利用しました。スペックは以下です。
- CPU: 2 vCPU
- Memory: 8 GiB
- Storage: 100 GB
- OS: Windows Server 2022 Standard Edition
-
セッションを作成（1つ目のセッションなのでAが振られてます）
-
セッションを複製していきます。5つ作成して、Eに。
3. あとはひたすら繰り返します。
Zの次はaに。
zの次はAAに。
検証結果1
AAあたりまではサクサクとセッションが起動していきました。
しかし、、、
AOくらいからはセッションの起動にもっさり感が出ててきました。
AR
AS
ATまでくるとセッション起動まで時間がかかるようになり。。
AUではセッション番号は振られたものの、5250画面は表示されず、10秒ほど経つとACS自体がハングして落ちました。。
検証結果2
再度、同じ方法で試しましたが、AUの起動タイミングで同様にACS落ちました。（再現性がありました）
作成できたセッションはATまでだったので、76セッションということになります。
追加検証
スペックに依存する可能性を確かめるために、VSI（クライアント）のスペックを2倍にして再度検証しました。
- CPU: 4 vCPU
- Memory: 16 GiB
- Storage: 100 GB
- OS: Windows Server 2022 Standard Edition
さて結果は？？
追加検証結果
結果は同じでした。。。
AUセッションの作成でACSがダウンしました。
結論
今回の検証においては、ACSでの同時セッション数の最大値は76でした。
クライアントのスペックには依存してないようです。
76に達する前から、徐々にACSのセッション起動が重くなっていったので、Java関連のチューニングで結果が変わる可能性はありかもです。
補足
同じIBM iに対してAAまでの53セッションを2つのクライアントから接続したところ、同時に106セッションは確立できたのでIBM i側の限界ではなく、クラアント側の限界に先に到達したものことは確認済みです。
まとめ
これほどのセッションを一つのクライアントから同時に実行するのは稀だと思いますが、何かのお役に立てれば幸いです。
理論的にはもっと接続できそうなので、またの機会にチューニング方法等も検討してみたいと思います。
チューニングポイントとか、ご存知の方いたら、コメントいただけると嬉しいです。