おそらく、TCP接続確立済のHTTPセッション数ではないかと思う。とりあえずメモ。
違いました。 id:yamadamn さんにコメントいただきました。
今更感のあるツッコミですが多分違います。
セッションという言葉は色々と使われますが、Servlet仕様のHttpSessionオブジェクトの数でしょうね。
https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.htmlWLSとしてはOpenSessionsCurrentCountとして取得できるものを指しているはずです。
EM監視メトリックのWeblogicのアクティブ・セッションは何か - ablog
https://docs.oracle.com/cd/E26854_01/em.121/b70510/wls.htm
https://docs.oracle.com/middleware/12212/wls/WLACH/pagehelp/J2EEappdeploymentsmonitorwebapptabletitle.html
教えていただいたServlet仕様のHttpSessionについて一部引用。
The servlet container uses this interface to create a session between an HTTP client and an HTTP server. The session persists for a specified time period, across more than one connection or page request from the user. A session usually corresponds to one user, who may visit a site many times. The server can maintain a session in many ways such as using cookies or rewriting URLs.
HttpSession (Java(TM) EE 7 Specification APIs)
サーブレットにアクセスしてHttpSessionオブジェクトが生成されるとWeblogicなどのJavaアプリケーションサーバでHttpSessionオブジェクトは一定期間生存する。従って、「HttpSessionオブジェクトの数 >= TCPセッション数」となると思われる。
http(s)はステートレスなプロトコル、keep-alive を使うと接続を維持するが*1、通常 keep-alive(十数秒〜1分とか)よりもセッションタイムアウト(20分とか)のほうが長いことが多い。
例えば、ブラウザでアクセスしてHttpSessionオブジェクトが生成された後、ブラウザを「×」で落として、起動してアクセスすると前のHttpSessionオブジェクトが残って、これを繰り返すとセッション数はどんどん増えると思われる。
ちなみに元々のTCPセッション的な意味で取得するのでしたら、OpenSocketsCurrentCountですね。
https://docs.oracle.com/middleware/12212/wls/WLACH/pagehelp/Corecoreserverservertitle.htmlさっき貼ったEMのマニュアルのURLだと"アクティブ・ソケット"って書いてあるほうですね。
EM監視メトリックのWeblogicのアクティブ・セッションは何か - ablog
こちらも教えていただいたマニュアルから一部引用。
Currently Open Sockets: The current number of sockets registered for socket muxing on this server.
Servers
以下は一応残しておく。
Systems Performance: Enterprise and the Cloud
- 作者: Brendan Gregg
- 出版社/メーカー: Prentice Hall
- 発売日: 2013/10/26
- メディア: ペーパーバック
- この商品を含むブログを見る
- 10.4. Architecture
- 10.4.1. Protocols
Three-Way Handshake
Connections are established using a three-way handshake between the hosts. One host passively listens for connections; the other actively initiates the connection. To clarify terminology: passive and active are from [RFC 793]; however, they are commonly called listen and connect respectively, after the socket API. For the client/server model, the server performs listen and the client performs connect.
The three-way handshake is pictured in Figure 10.6.
The TCP protocol was described earlier. This section describes performance features of the kernel TCP implementation: backlog queues and buffers.
Bursts of connections are handled by using backlog queues. There are two such queues, one for incomplete connections while the TCP handshake completes (also known as the SYN backlog), and one for established sessions waiting to be accepted by the application (also known as the listen backlog). These are pictured in Figure 10.10.
Only one queue was used in earlier kernels, and it was vulnerable to SYN floods. A SYN flood is a type of DoS attack that involves sending numerous SYNs to the listening TCP port from bogus IP addresses. This fills the backlog queue while TCP waits to complete the handshake, preventing real clients from connecting.
With two queues, the first can act as a staging area for potentially bogus connections, which are promoted to the second queue only once the connection is established. The first queue can be made long to absorb SYN floods and optimized to store only the minimum amount of metadata necessary.
The length of these queues can be tuned independently (see Section 10.8, Tuning). The second can also be set by the application as the backlog argument to listen().
