On 28.03.2018 13:13, PANG J. wrote:
As shown below,
Last day total requests are 42,368,982, not all are successful, but 42,362,363
are right.
The failed requests are timeout.
OK, that is quite an impressive number of requests, and a good answer to people who always
wonder if an Apache/mod_perl/perl solution is really scaleable..
(Perl/mod_perl advocates, take note)
5619 failed requests, on a total of 42,368,982 is approximately a 0,013%
failure rate.
That does no really look like justifying a complete architecture change.
Can you maybe reprogram the client-side app, to wait for a "normal" time, and if there is
a timeout, ask the user if they want to continue waiting, or abort the call ?
(According to the numbers above, such a message should only appear in 0,013% of the cases,
and the other 42,362,363 (99.987%) clients will never see it.)
Thanks.
On 2018/3/28 星期三 PM 6:37, André Warnier (tomcat) wrote:
On 28.03.2018 12:31, PANG J. wrote:
what the client I meant is mobile App.
mobile App gets the result from server via SDK.
Ok. But it is very likely that your "mobile app SDK", also has a timeout after
it sends
a request to a server. Or are you /sure/ that it waits forever ?
/Precisely what/ makes you think that it is a server-side timeout ?
in future we may move the computing task into App itself.
But currently they are running on server side.
thanks.
On 2018/3/28 星期三 PM 6:11, André Warnier (tomcat) wrote:
I believe that the timeout which Pang J. is mentioning, may be the browser-side
timeout,
which is fixed at the browser level at about 5 minutes or so.
When a browser sends a request to a server, and it does receive /some/ response
within
the next +-5 minutes, then the browser will drop the connection to the server,
and pop
up a message saying "sorry, the server appears not to respond.."
In other words, it is not a server timeout, it is a client timeout.
The only way to avoid this, is to insure that the server sends at least /some/
temporary
response to the client (*), regularly, so that this browser timeout does not
occur.
Unfortunately, that is a bit more complicated to set up, than just some
parameter
somewhere.
But there must be plenty of past discussions of this issue already on the www,
and
solution guidelines.
