Welcome! Log In Create A New Profile

Advanced

Re: Quick performance deterioration when No. of clients increases

All files from this thread

File Name File Size   Posted by Date  
load_impact_1.png 55.5 KB open | download Nikolaos Milas 10/11/2013 Read message
graphes-Perfs-rate_tn.png 3 KB open | download Nikolaos Milas 10/16/2013 Read message
graphes-Users_Arrival-rate_tn.png 3.4 KB open | download Nikolaos Milas 10/16/2013 Read message
graphes-Users-simultaneous_tn.png 2.9 KB open | download Nikolaos Milas 10/16/2013 Read message
graphes-Errors-rate_tn.png 3.3 KB open | download Nikolaos Milas 10/16/2013 Read message
graphes-Perfs-mean_tn.png 3.1 KB open | download Nikolaos Milas 10/16/2013 Read message
compare.png 23.5 KB open | download Nikolaos Milas 10/16/2013 Read message
October 19, 2013 02:12PM
This is a slight oversimplification as processes in waitio are also adding to the load average. Use of programs like top, iotop, mytop etc will give you a clearer idea of what is going on, and where your bottleneck lies.

Steve

Jan-Philip Gehrcke <jgehrcke@googlemail.com> wrote:

>Hi Nikolaos,
>
>just a small follow-up on this. In your initial mail you stated
>
> > The new VM (using Nginx) currently is in testing mode and it only has
> > 1-core CPU
>
>as well as
>
> > When this performance deterioration occurs, we don't see very high CPU
> > load (Unix load peaks 2.5)
>
>These numbers already tell you that your initial tests were CPU bound. A
>simple way to describe the situation would be that you have loaded your
>system with 2.5 as much as it was able to handle "simultaneously". On
>average, 1.5 processes were in the run queue of the scheduler just
>"waiting" for a slice of CPU time.
>
>In this configuration, you observed
>
> > You can see at the load graph that as the load approaches 250 clients,
> > the response time increases very much and is already unacceptable
>
>Later on, you wrote
>
> > In the meantime, we have increased CPU power to 4 cores and the behavior
> > of the server is much better.
>
>and
>
> > Now my problem is that there seems to be a limit of performance to
> > around 1200 req/sec
>
>Do you see that the rate increased by about factor 4? No coincidence, I
>think these numbers clarify where the major bottleneck was in your
>initial setup.
>
>Also, there was this part of the discussion:
>
> > On 16/10/2013 7:10 μμ, Scott Ribe wrote:
> >
> >> Have you considered not having vastly more worker processes than you
> >> have cores? (IIRC, you have configured things that way...)
> >
> > I have (4 CPU cores and):
> >
> > worker_processes 4;
>
>
>Obviously, here you also need to consider the PHP-FPM and possibly other
>processes involved in your web stack.
>
>Eventually, what you want at all times is to have a load average below
>the actual number of cores in your machine (N) , because you want your
>machine to stay responsive, at least to internal events.
>
>If you run more processes than N that potentially create huge CPU load,
>the load average is easily pushed beyond this limit. Via a large request
>rate, your users can then drive your machine to its knees. If you don't
>spawn more than N worker processes in the first place, this helps
>already a lot in preventing such a user-driven lockup situation.
>
>Cheers,
>
>Jan-Philip
>
>
>
>
>
>
>
>
>
>
>
>On 16.10.2013 18:16, Nikolaos Milas wrote:
>> On 16/10/2013 7:10 μμ, Scott Ribe wrote:
>>
>>> Have you considered not having vastly more worker processes than you
>>> have cores? (IIRC, you have configured things that way...)
>>
>> I have (4 CPU cores and):
>>
>> worker_processes 4;
>> worker_rlimit_nofile 400000;
>>
>> events {
>> worker_connections 8192;
>> multi_accept on;
>> use epoll;
>> }
>>
>> Any ideas will be appreciated!
>>
>> Nick
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
>_______________________________________________
>nginx mailing list
>nginx@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Quick performance deterioration when No. of clients increases Attachments

Nikolaos Milas October 11, 2013 04:08AM

Re: Quick performance deterioration when No. of clients increases

GreenGecko October 11, 2013 04:20AM

Re: Quick performance deterioration when No. of clients increases

Dennis Jacobfeuerborn October 11, 2013 07:26AM

Re: Quick performance deterioration when No. of clients increases

Nikolaos Milas October 12, 2013 10:00AM

Re: Quick performance deterioration when No. of clients increases

Toni Mueller October 14, 2013 10:48AM

Re: Quick performance deterioration when No. of clients increases Attachments

Nikolaos Milas October 16, 2013 06:34AM

Re: Quick performance deterioration when No. of clients increases Attachments

Nikolaos Milas October 16, 2013 12:08PM

Re: Quick performance deterioration when No. of clients increases

Scott Ribe October 16, 2013 12:12PM

Re: Quick performance deterioration when No. of clients increases

Nikolaos Milas October 16, 2013 12:18PM

Re: Quick performance deterioration when No. of clients increases

Scott Ribe October 16, 2013 12:24PM

Re: Quick performance deterioration when No. of clients increases

Jan-Philip Gehrcke October 19, 2013 07:58AM

Re: Quick performance deterioration when No. of clients increases

Nikolaos Milas October 17, 2013 03:52AM

Re: Quick performance deterioration when No. of clients increases

Aidan Scheller October 11, 2013 08:38AM

Re: Quick performance deterioration when No. of clients increases

GreenGecko October 19, 2013 02:12PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 110
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready