Understanding session rate in stats


#1

This is related to my previous post titled “keepalive not working on backend”. In troubleshooting the issue we modified our configuration to a very simple single frontend and single backend with “http-reuse safe” enabled as well as the default “http-keep-alive”. However, the session rate in the statistics page shows several hundred new connections per second, but if we examine the number of syn packets being sent from our haproxy server to the single backend server the session rate appears to be around 1 or 2 new sessions per second.

Is my understanding of session rate incorrect? Does this represent something else other than new connections per second. The fact that we see a very small number of syn packets makes sense given our config, but the session rate in the statistics page does not.

Thanks.


#2

I think your understanding is incorrect. Hopefully this (taken from my post on the same subject here: https://devcentral.f5.com/questions/connections-vs-sessions) will help:

"HTTP Is considered to be a stateless protocol in that the client and server do not store state data in any way. A request is sent and a response received; this ‘transaction’ has no impact on future ones, nor do earlier ones affect this one. Cookies are used to provide a form of state when required.

Multiple transactions between the same client and server, completed over the same established TCP connection are considered a session. A session may also comprise of multiple TCP connections (again between the same client and server) to improve performance. Sessions rely on HTTP Persistent Connections.

Session persistence is only required where a single session uses multiple TCP connections - we need to ensure the second, third… connection in that session is sent to the same real server. This ensures that any state information stored only on that server (outside of HTTP), related to the session the connections form a part of, is valid. If those connections were Load Balanced to different servers the lack of the session state context (and loss of server affinity) will most likely result in application errors."


#3

Thanks for the reply. I read your blog post and do have a couple of
questions. What we are trying to achieve with haproxy is idle http
connection reuse along with ssl resumption on the frontend and backends.

In our particular haproxy config, there is a one-to-one mapping of Host
header to backend server, so it’s not a concern for us to have traffic hit
different backend servers. What metric in the haproxy stats would reveal
that we are indeed reusing idle http connections if it’s not session rate
as it sounds like from what you are saying is the session count will
increase every time there is a new http request made.

Another point of confusion is that the session rate on our frontends is
very low but one the backends very high. So, it seems we are achieving the
desired result on the frontend but not backend.


#4

Hey @bwmetcalf,

On closer inspection, I don’t think the statistics are helpful because perhaps HAProxy doesn’t make a distinction between connections and sessions. It ridiculously hard to decipher and there is no explanation I can find anywhere as to what HAProxy considers a session.

The output of show info shows the number of current connections, but not the number of current sessions.

The output of show stat shows the number of current sessions, but not connections.

Personally, until I know better, I would not rely on these statistics for this kind of analysis.

I’d suggest you are better off using ss and the like to confirm you have fewer connections from the HAProxy host to a server than you have from clients to the associated front end/proxy.