Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

3CX SBC Platforms

Discussion in '3CX Phone System - General' started by DSXDATA, Jan 24, 2017.

Thread Status:
Not open for further replies.
  1. DSXDATA

    DSXDATA New Member

    Joined:
    Oct 20, 2015
    Messages:
    185
    Likes Received:
    64
    Now that the SBC is available on Debian, there are a wide range of choices. Obviously, the objective is to match cost with the performance required. We installed Debian on three platforms, Pi (~$50), MicroInspiron (~$150), NUC (~$250) and measured performance so we could better deploy SBC platforms based on performance requirements. Here are the raw results:

    Test run: sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run

    Raspberry Pi 3
    ARMv7 Processor rev 4 (v7l)

    Test execution summary:
    total time: 193.1938s
    total number of events: 10000
    total time taken by event execution: 772.5933
    per-request statistics:
    min: 76.35ms
    avg: 77.26ms
    max: 302.59ms
    approx. 95 percentile: 79.32ms

    Threads fairness:
    events (avg/stddev): 2500.0000/21.12
    execution time (avg/stddev): 193.1483/0.03
    ======================================================
    Intel NUC NUC5PPYH
    Intel(R) Pentium(R) CPU N3700 @ 1.60GHz

    Test execution summary:
    total time: 10.5512s
    total number of events: 10000
    total time taken by event execution: 42.1857
    per-request statistics:
    min: 4.18ms
    avg: 4.22ms
    max: 19.51ms
    approx. 95 percentile: 4.21ms

    Threads fairness:
    events (avg/stddev): 2500.0000/3.24
    execution time (avg/stddev): 10.5464/0.00
    ======================================================
    Dell MicroInspiron 3050
    Intel(R) Celeron(R) CPU J1800 @ 2.41GHz

    Test execution summary:
    total time: 21.0968s
    total number of events: 10000
    total time taken by event execution: 84.3438
    per-request statistics:
    min: 4.21ms
    avg: 8.43ms
    max: 21.76ms
    approx. 95 percentile: 12.22ms

    Threads fairness:
    events (avg/stddev): 2500.0000/7.52
    execution time (avg/stddev): 21.0859/0.01
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    accentlogic likes this.
  2. accentlogic

    accentlogic New Member

    Joined:
    Nov 14, 2013
    Messages:
    181
    Likes Received:
    77
    Thanks for sharing. I have been hammering a few RPi units to see how they do. So far no issues with up to about 8 extensions loaded with BLF keys and Shared Parking. (I have not tried to go beyond that.)

    Also very interesting to see the other two units with very similar metrics. Any feel yet how these benchmarks translate to suitability in a production environment?
     
  3. Nathan Boyd

    Joined:
    Feb 2, 2017
    Messages:
    46
    Likes Received:
    11
    I've had no issues running 10 extensions behind a Pi3 both on V14 SBC and the pdated V15 SBC with Encryption enabled. Both had roughly 5 BLFs for each phone as well. As I understand it, the updated V15 Pi SBC is now multi-threaded as well and so it's capabilities have risen tremendously.
     
  4. DSXDATA

    DSXDATA New Member

    Joined:
    Oct 20, 2015
    Messages:
    185
    Likes Received:
    64
    The BLF's are what stress the SBC with the constant signalling required to update status. I think 10 phones is a safe guess if BLF's are in use; if not 20 phones are probably possible but personally I'd move up to a beefier box. You can use HTOP to watch the cpu usage in realtime from SSH.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. Nathan Boyd

    Joined:
    Feb 2, 2017
    Messages:
    46
    Likes Received:
    11
    Absolutely. And that's my point. Obviously it's not a fit in every case, but the Pi3 and the new multithreaded SBC are much more efficient with overall horsepower than previous software versions.

    Just watched "top" on the Pi that's running in my office with 8 Yealink T46s each holding roughly 8 BLFs (between SP's and Ext BLFs) and it's idling around .3%. Occasionally bouncing up to 2% for a few and then back down. With 2 concurrent calls, it was at a steady 1% and then bounces to 2% processing the hangup BLF changes before idling again. See screenshot.

    I have no doubt in my mind that 3CX's sizing recommendations are correct with the new Pi and SBC.
     

    Attached Files:

  6. bbaker73

    bbaker73 New Member

    Joined:
    Nov 27, 2015
    Messages:
    144
    Likes Received:
    26
    Good info. We're hosting several 3cx servers and are trying to decide what to do with the remote sites. Currently STUN with no SBC or remote firewall config. For the most part they run fine. 3cx support though, always wants to see static ip on the phones and remote firewall forwarding or SBC. We didn't like the idea of single point failure for the SBC. So I'm trying to decide whether to make SBC standard with these and future hosts, but needs to be cost effective and manageable. Some of these sites have little infrastructure and I don't want to place servers there out of my control. I'm thinking to use multiple Pi3 and load balance so at least if one goes down, they don't lose all phones. and maybe have a standby offline. I can look at micro/mini pc's or full servers that can handle more, but those would be more expensive especially to have a load balance or backup spare. You guys seem happy with the Pi3. My remote sites range 5, 10, 20, 40+ phones with probably 5-10 BLF's/phone. What do you think of this multi Pi approach or should I think otherwise?
     
  7. Nathan Boyd

    Joined:
    Feb 2, 2017
    Messages:
    46
    Likes Received:
    11
    I think that might just be overkill. I'm totally comfortable with a Pi3 at up to 20ish phones with BLFs. Beyond that, you'd want the horsepower of an x86 machine and 3CX just released the x86 Debian flavor of SBC.

    Regarding redundancy, At $50/kit it's trivial to keep a spare Pre-configured Pi onsite for the smaller locations. My oldest one is almost 2 years old and hasn't had any issues, yet. The issues I have had with Pi's have much more often been with the power supplies than the board or SD Cards. But for the larger sites, chances are you'll have more infrastructure, maybe run the X86 debian version as a VM?
     
    bbaker73 likes this.
  8. accentlogic

    accentlogic New Member

    Joined:
    Nov 14, 2013
    Messages:
    181
    Likes Received:
    77
    +1 on what Nathan said. We plan to use a Pi3 up to 20 extensions, with a hot spare for any site of 5 or more. (Maybe fewer.)

    If we have over 20, it will be a Debian based micro PC, plus a Pi3 or another micro PC hot spare.

    We are installing ScreenConnect on both the Pi3 and Debian installs - as well as Windows. They phone home so there is zero to do on the firewall.

    Running a Debian VM on enterprise hardware is also a great idea.
     
    bbaker73 likes this.
  9. Nathan Boyd

    Joined:
    Feb 2, 2017
    Messages:
    46
    Likes Received:
    11
    +1 to AccentLogic, comments about ScreenConnect as well! That's what we do as well for remote administration/upgrade also. Only way to fly!
     
Thread Status:
Not open for further replies.