Thanks Andre for so much info.
Yes we do have statistics for the requests in terms of how long they take:
As you see, 99.996% are less than 100ms, 0.002% are between 100ms and
200ms, another 0.002% are greater than 200ms. Max QPS is 2314.
You just remind me that timeout is may due to network
You can also turn on "keep-alive" and tune it to suit your current, immediate
need.
-Jie
Hi.
This is a bit of a different discussion, which is why I am now marking it OT.
I was quite impressed by the numbers you list below (and I still am,
nevertheless).
So my first impression was that I am totally incompetent to comment further, because I
have never dealt with such numbers, and I
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/mo
On 28.03.2018 12:54, PANG J. wrote:
I do think it's a client timeout.
Ok, then there are many kinds of answers to your question..
1) the quick and dirty solution, is to find out how to set the timeout higher in your app
SDK, and set it high enough so that the timeout never happens.
As far as
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.
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 A
I do think it's a client timeout.
regards.
On 2018/3/28 星期三 PM 6:37, André Warnier (tomcat) wrote:
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 i
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/
for long run stuff, people are usually using job queue like gearman,
theschwartz or minion etc.
you can send a ID back to app first, then init another request with
that id to check if it's finished.
Thanks
On Wed, Mar 28, 2018 at 6:31 PM, PANG J. wrote:
> what the client I meant is mobile App.
what the client I meant is mobile App.
mobile App gets the result from server via SDK.
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.
Addendum : searching Google for "avoid browser timeout" gets plenty of answers, among
which this is a perl-oriented one : https://www.perlmonks.org/bare/?node_id=252682
with further links.
On 28.03.2018 12:11, André Warnier (tomcat) wrote:
Hi.
Are we not a bit on the wrong track here ?
I belie
Hi.
Are we not a bit on the wrong track here ?
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 +
12 matches
Mail list logo
