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.
we are still calculating.."
As long as the browser receives /some/ response regularly, it will not time out.
On 28.03.2018 05:11, Jie Gao wrote:
* PANG J. wrote:
Date: Wed, 28 Mar 2018 10:49:46 +0800
From: "PANG J."
To: modperl@perl.apache.org
Subject: Re: handler timeout
User-A
rl@perl.apache.org
Subject: Re: handler timeout
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.6.0
On 2018/3/28 星期三 AM 10:41, Jie Gao wrote:
To start with, is your hosting machine running out of resources (CPU cycles,
memory, etc)?
No. resources are enough.
* PANG J. wrote:
> Date: Wed, 28 Mar 2018 10:49:46 +0800
> From: "PANG J."
> To: modperl@perl.apache.org
> Subject: Re: handler timeout
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.6.0
>
>
>
> On 2018/3/
On 2018/3/28 星期三 AM 10:41, Jie Gao wrote:
To start with, is your hosting machine running out of resources (CPU cycles, memory, etc)?
No. resources are enough. we have about 100 servers for computing, each
with 24 physical cores. But yes, the system load most time is high.
And what is t
* PANG J. wrote:
> Date: Wed, 28 Mar 2018 10:17:33 +0800
> From: "PANG J."
> To: modperl@perl.apache.org
> Subject: Re: handler timeout
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.6.0
>
> Hi,
>
> what th
Hi,
what the primary reason is handler computes for long time, so client
gets timeout.
On 2018/3/28 星期三 AM 10:08, Jie Gao wrote:
* PANG J. wrote:
Date: Wed, 28 Mar 2018 09:30:17 +0800
From: "PANG J."
To: modperl@perl.apache.org
Subject: handler timeout
User-Agent: Mozilla/5.0 (Windows N
* PANG J. wrote:
> Date: Wed, 28 Mar 2018 09:30:17 +0800
> From: "PANG J."
> To: modperl@perl.apache.org
> Subject: handler timeout
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.6.0
>
> Hi,
>
> there are a lot of Floating point operations in my mod
17 matches
Mail list logo
