raw-h2: connection pool design about aapns HOT 11 CLOSED

• initialise and enter context, that creates N connections (perhaps N=1)

Did you check if APNS will just close idle connections if they're opened but then for a while no request is made?

from aapns.

• initialise and enter context, that creates N connections (perhaps N=1)

Did you check if APNS will just close idle connections if they're opened but then for a while no request is made?

I've tested exponentially increasing delays between requests.
(so a connection has had a successful request, and now there's a long gap).
a 1024s idle period does not kill the connection.

I'll test a fresh unused connection being idle next.

from aapns.

IMHO the priorities should be:

1. Stability (doesn't crash weirdly all the time).
2. Throughput (doesn't crash under load and can send tons of notifications if needed).
3. Latency (this library is such a small part of the overall latency that optimizing this last seems reasonable).

So I'd prefer a simple design (eg no background refresh because that seems like a prime source of trouble) sacrificing some performance if needed. If/once we have an actual reliable h2 client (which this library sadly never had) we can worry about latency etc.

from aapns.

• exit the context, all connections are closed

In Real-time use case, when or how often does it happen?

from aapns.

@ojii indicated that he'd start the connection pool at the start of the server.
It may only be closed when the server is shutting down.
(in other words, basically never)

I figure that's a common use-case for the cloud.

from aapns.

• a connection does not allow more than e.g. 10 concurrent requests

why? as in, why not use the max concurrency as advertised by the server

from aapns.

• a connection does not allow more than e.g. 10 concurrent requests

why? as in, why not use the max concurrency as advertised by the server

To ensure low latency;
Somehow latency is proportional to how "busy" a connection is.

from aapns.

As far as I can see the latency difference between them are not that significant (less than 1s) the biggest latency would be from APN Server - Mobile Device itself, which can take seconds more.

I'd be in favour of N>=2 + Many streams like the Batch-use case for general use

from aapns.

re: ↑ what throughput are you thinking of? how many requests per second?

from aapns.

re: ↑ what throughput are you thinking of? how many requests per second?

that's really hard to answer. "as much as possible"/"it depends"? we never benchmarked the v1 (my custom terrible h2 client) or v2 (httpx) so I have no baseline, and as you learned, getting good numbers is almost impossible because you need lots of real devices (with a push-enabled app installed) to do much.

from aapns.

Thank you all for your input.
I've settled on naive connection pool for now.
Hopefully the pros are:

• stability
• durability in face of network errors
• throughput
• [kinda] latency, by overprovisioning pool size
  For cons, I'll open new tickets.

from aapns.