On 2016-05-16, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
> Grant, the bad news is that I know this because our firware guy had
> _exactly_ this problem, with exactly your scenario, about a month ago.
> http, not https, but the problem remains the same but for some heavy
> math. After a lot of door knocking, poking, prodding, and hoping, the
> conclusion he reached was that what you want can't be done,
Bummer.
> and he had to gut and redesign the web server to support parallel
> connections.
Mine does (in effect) support parallel connections. With HTTP it all
works fine: browser opens 4-5 connections in parallel; sends requests
on all of them; responses come back on all of them. A few of the
connections then get reused for additional requests, and so on.
> Turned a 45 second page load into south of one, but it wasn't pretty and
> chewed up a bunch of RAM. We had 256K to play in; I'm assuming you've
> got closer to 32K.
I've actually got plenty of RAM. I just can't afford the CPU time it
takes to do the public-key crypto stuff that happens each time an SSL
connection starts up.
I'm hoping that if I refuse additional connections (or stall them
before the SSL handshake), I can convince the browser to make use of
extant connections.
However, in my case, there are some cases where a connection can't be
re-used because the server doesn't know how big the reply is going to
be and the only way to identy "end of reply" is for the server to
close the connection. In theory I can fix that by adding support to
the server for chunked encoding in the cases where the reply size is
unknown. But that won't do me any good if the browser opens 4 more
connections before it's even seen the response from the first one.
--
Grant Edwards grant.b.edwards Yow! I'm having a RELIGIOUS
at EXPERIENCE ... and I don't
gmail.com take any DRUGS
--
https://mail.python.org/mailman/listinfo/python-list
