Laravel-websockets: Server Setup

Created on 24 May 2019  路  9Comments  路  Source: beyondcode/laravel-websockets

In Documentation: https://docs.beyondco.de/laravel-websockets/1.0/faq/scaling.html

You were able to achieve:
"Here is another benchmark that was run on a 2GB Digital Ocean droplet with 2 CPUs. The maximum number of concurrent connections on this server setup is nearly 60,000"

I have tried with same server configuration on DO with Ubuntu.

I tested with Artillery:

config:
  target: "wss://rtc.xxx.com:443/app/websocketkey?protocol=7&client=js&version=4.4.0&flash=false"
  phases:
    - duration: 120
      arrivalRate: 40
      rampTo: 40
      name: "Ramping up the load"
scenarios:
  - engine: "ws"
    flow:
      - send: '{"event":"pusher:subscribe","data":{"channel":"public"}}'
      - think: 15

On server I am using nginx with reverse proxy (https://docs.beyondco.de/laravel-websockets/1.0/basic-usage/ssl.html#usage-with-a-reverse-proxy-like-nginx)

The server is created using forge, so I run php artisan websockets:serve using Daemon.

I have increased number of file descriptors. I have installed pecl event.

When I run artillery, I get max of 600 concurrent users. If I increase arrivalRate to more than 40, I get errors like:

  Scenarios launched:  0
  Scenarios completed: 603
  Requests completed:  0
  RPS sent: NaN
  Request latency:
    min: NaN
    max: NaN
    median: NaN
    p95: NaN
    p99: NaN

Is there anything I am missing, which is not giving me similar performance?

question

All 9 comments

Hi there. I'm facing the same scenario.

I've tested on a 1GB Vultr Droplet and get the same 600 concurrent users.

I'm using it without reverse proxy and SSL.

I think I've found the solution. Checkout this link: https://docs.beyondco.de/laravel-websockets/1.0/faq/deploying.html

At first time only runing the "ulimit -n 10000" didn't worked (even temporarily).

What I did was adopt the fixed solution:

/etc/security/limits.d/my-user.conf
my-user hard nofile 999999 (six-9)
my-user soft nofile 999999 (six-9)

After create this file I had to restart the server to take effect.

Right now I'm testing about 1200 concurrent users and the CPU load is about 25%.

I'll do more tests.

I've found these article today: http://kemalcr.com/blog/2016/11/13/benchmarking-and-scaling-websockets-handling-60000-concurrent-connections/

As soon I deploy more machines to help me testing the server load I'll post the tests here.

I have configured nginx too: "worker_rlimit_nofile 65535;" Instead "999999" I used "65535".

Try to install 'ev' extension using pecl.

Did tou tested using another tool than artillery?

In my lastest test I got about 3400 connections. I've used tsung simultaneosly in this machines:

  • 1 Vultr 1GB VPS (generating 1300 arrival connections)
  • 1 notebook (generating 300 arrival connections)
  • 6 docker containers in my desktop (each one generating 300 arrival connections)

The peak CPU usage I've noticed was about 32% percent.

Is your tsung config anything similar to the following:

<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/user/share/tsung/tsung-1.0.dtd">
<tsung loglevel="notice" version="1.0">
  <clients>
    <client host="tsung-machine" use_controller_vm="false" maxusers="64000" />
  </clients>

  <servers>
    <server host="134.209.154.159" port="6001" type="tcp" />
  </servers>

  <load>
    <arrivalphase phase="1" duration="60" unit="second">
      <users maxnumber="100000" arrivalrate="10" unit="second" />
    </arrivalphase>
  </load>

  <sessions>
    <session name="websocket" probability="100" type="ts_websocket">
        <request>
             <websocket type="connect" path="/app/websocketkey"></websocket>
        </request>

        <request subst="true">
            <websocket type="message">{"event":"pusher:subscribe","data":{"channel":"public"}}</websocket>
        </request>

        <for var="i" from="1" to="2" incr="1">
          <thinktime value="5"/>
        </for>
    </session>
  </sessions>
</tsung>

Yes. I've used almost the same parameters.

The only difference was in 'load' section. I've used an arrival rate depending the machine I was testing.





Did you use Supervisor?

Was this page helpful?
0 / 5 - 0 ratings