Nginx flv stream gets too slow on 2000 concurrent connections

shahzaib shahzaib shahzaib.cb at gmail.com
Wed Jan 23 14:14:03 UTC 2013


Thanks for helping me out guyz but w're already dealing with 3-app servers
clustering with haproxy load balancer (For this video streaming site), and
can't afford another clustering type things. You're talking about Haproxy
load-balancer to split required flv files requests to different servers.
We'll have to buy 5 more content servers for mirroring data between every
two servers to split load-balancer requests but the problem is we're
running out of budget. If you can provide me some alternate to this problem?


On Wed, Jan 23, 2013 at 6:33 PM, Geoffrey Hartz <hartz.geoffrey at gmail.com>wrote:

> It will not help you actualy but I had a similar experience.
>
> My issue was due to the system event handle (epoll, kqueue...)
>
> I noticed poor speed when hitting 2000 connections with haproxy. So I
> switch to nginx + tcp module proxy. Same results..
>
> But using haproxy + nginx (with two different event handler, I avoid
> the speed problem). At the end, I prefered use ESXi and 2/3 VM and
> split connections with DNS load balancing
>
> Maybe you should take a look at this event handler problem and do some
> tunning on kernel/OS. Nginx (maybe) isn't the actual issue.
>
> 2013/1/23 shahzaib shahzaib <shahzaib.cb at gmail.com>:
> > The average size of each flv video is 60Mb+. We've five content servers
> > (nginx-1.2.1), each with 1Gbps port and 100TB bandwidth per month. Right
> now
> > each server is consuming 10~12 bandwidth per day and we're going to run
> out
> > of bandwidth on coming last days of month. However we limited every
> > connection to 180k, you can see limit_rate 180k; in nginx.conf file.
> >
> > I am newbie to this field. Please correct me if i didn't satisfy your
> > question regarding bandwidth. :)
> >
> >
> > On Wed, Jan 23, 2013 at 5:39 PM, Dennis Jacobfeuerborn
> > <dennisml at conversis.de> wrote:
> >>
> >> On 01/23/2013 10:43 AM, shahzaib shahzaib wrote:
> >> > Hello,
> >> >
> >> >         We are using nginx to serve large size of static files i.e
> >> > jpg,flv
> >> > and mp4 . Nginx stream works very well on 1000~1500 concurrent
> >> > connections
> >> > but whenever connections exceeded to 2000~2200, stream gets too slow.
> >> > We've
> >> > five content server with following specification:-
> >> >
> >> > Dual Quard Core (8cores/16threads)
> >> > RAM = 32G
> >> > HDD = Sas Hard-Raid 10
> >> >
> >> >
> >> > My nginx.conf config is given below :
> >> >
> >> > user  nginx;
> >> > worker_processes  16;
> >> > worker_rlimit_nofile 300000; #2 filehandlers for each connection;
> >> >
> >> > #pid        logs/nginx.pid;
> >> >
> >> >
> >> > events {
> >> >     worker_connections  6000;
> >> >     use epoll;
> >> > }
> >> > http {
> >> >     include       mime.types;
> >> >     default_type  application/octet-stream;
> >> >     limit_rate 180k;
> >> >     client_body_buffer_size 128K;
> >> >     sendfile_max_chunk 128k;
> >> >     server_tokens off; #Conceals nginx version
> >> >     access_log off;
> >> >     sendfile        on;
> >> >     client_header_timeout  3m;
> >> >     client_body_timeout 3m;
> >> >     send_timeout     3m;
> >> >     keepalive_timeout  0;
> >> >
> >> > If somebody can help me improving nginx config will be helpful to
> him. I
> >> > apologize for bad engish :D
> >>
> >> What's the required bandwidth for the flv files? What is the bandwidth
> of
> >> the connection of the system? What is the bandwidth of the uplink to the
> >> Internet?
> >>
> >> Regards,
> >>   Dennis
> >>
> >> _______________________________________________
> >> nginx mailing list
> >> nginx at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx
> >
> >
> >
> > _______________________________________________
> > nginx mailing list
> > nginx at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>
> --
> Geoffrey HARTZ
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130123/ff008d81/attachment.html>


More information about the nginx mailing list