high bandwidth configuration help

nginx.mailinglist nginx.mailinglist at xinio.info
Mon Feb 25 19:41:35 MSK 2008

Increasing buffer size and number of workers from 1 only made things worse,
at one stage the laod started spiraling above 20 its down to 4 now on the 2

Right now im very screwed, the performance loss from switching to nginx is
killing the servers, i also setup 2nd server identically

the graphs speak for themselves :(

server converted yesterday

new server to the left of the dip is lighttpd

im now very screwed as i was gonna relly on nginx's accel-redirect feature
and lighttpd 1.4.18 has it, im testing lighttpd1.5 svn now but i dont know
how stable that be,
sorry for being so down :'{ i feel like crying this was certainly the worst
case scenraio when is started migrating, a 10-20% drop in bandwdith
usage between all the servers will mean 1000-2000$ loss due to wasted costs

On Mon, Feb 25, 2008 at 10:25 AM, Igor Sysoev <is at rambler-co.ru> wrote:

>  On Mon, Feb 25, 2008 at 09:45:57AM +0000, nginx.mailinglist wrote:
> > I changed to one worker and the loads have gone down, thanks (spasibo!)
> >  Igor
> >
> > tho bandwidth usage is still 10% lower than lighttpd im gonna test on
> other
> > servers now
> >
> > i will back report results
> As I understand for writev-backend lighttpd mmap()s file in 512K chunks
> and writev()s them. You may try in nginx
>   output_buffers   1  512k;  # default is "1 32k"
> The output_buffers are used if sendfile is not used.
> Also you may try to set 2 or 3 workers if it will increase bandwidth.
> Note, that disabling sendfile in both nginx and ligthy may increase
> bandwidth, but also ceratinly increases memory consumption at user- and
> kernel-level that may leave to DOS. You should find compromisse.
> --
> Igor Sysoev
> http://sysoev.ru/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080225/9c162a33/attachment.html>

More information about the nginx mailing list