# Using multiple cpu cores, any specific drawback?

**URL:** <https://discourse.haproxy.org/t/using-multiple-cpu-cores-any-specific-drawback/998>\
**Category:** Help!\
**Created:** [February 8, 2017, 7:43am UTC](https://discourse.haproxy.org/t/using-multiple-cpu-cores-any-specific-drawback/998 "2017-02-08T07:43:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jagbir](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jagbir](https://discourse.haproxy.org/u/jagbir)\
**Post date:** [February 8, 2017, 7:43am UTC](https://discourse.haproxy.org/t/using-multiple-cpu-cores-any-specific-drawback/998/1 "2017-02-08T07:43:15Z")

</div>

Our haproxy is receiving traffic where 80% requests are on http while 20% on https. We want to move entire traffic to HTTPS. Done some benchmarking, first with single core and then using multiple cpu cores and observed good performance improvements while using multiple cores. Scanned through documentation but not able to find any specific text about more challenges/issues which could occur except where multi core use is strongly discouraged. We are bit concerned after reading that statement and looking for some pointers to help us take more informed decision.

Config we are using with multi core enabled in AWS instance having 16 core cpu with 32 GB of RAM:

```
global
        log-send-hostname msg-haproxy-log.example.com

        log 127.0.0.1 local0
        log 127.0.0.1 local1 notice

        maxconn 500000
        user haproxy
        group haproxy
        daemon
        stats socket /var/run/haproxy.socket level admin
        tune.ssl.default-dh-param 2048
        nbproc 9
        cpu-map 1 0
        cpu-map 2 1
        cpu-map 3 2
        cpu-map 4 3
        cpu-map 5 4
        cpu-map 6 5
        cpu-map 7 6
        cpu-map 8 7
        cpu-map 9 8
        stats bind-process 9

defaults
        log global
        option dontlognull
        retries 3
        option redispatch
        maxconn 500000
        timeout connect 300000
        timeout client 660000
        timeout server 660000

frontend tcp-in
        mode tcp
        bind *:1883 
        bind *:8883 ssl crt /etc/ssl-certs/primary.pem
        option tcplog
        bind-process 1
        default_backend tcp-backend

frontend tcp-in2
        mode tcp
        bind *:2883
        bind *:9883 ssl crt /etc/ssl-certs/primary.pem
        option tcplog
        bind-process 2 3 4 5
        default_backend tcp-backend2

frontend api
        bind *:80
        bind *:443 ssl crt /etc/ssl-certs/primary.pem
        rate-limit sessions 6000
        monitor-uri /health-check
        mode http
        bind-process 6 7 8 9
        default_backend api-backend

backend api-backend
    balance roundrobin
    mode http
    option httplog
    server http1 192.168.0.141:8282 check
    server http2 192.168.0.141:8283 check
    server http3 192.168.0.141:8284 check
    server http4 192.168.0.141:8285 check
    server http5 192.168.0.141:8286 check
    

backend tcp-backend
       option forwardfor except 127.0.0.1
        balance roundrobin
        mode tcp
        option tcplog
        server mqtt1 192.168.0.141:3883 check
        server mqtt2 192.168.0.141:3884 check
        server mqtt3 192.168.0.141:3885 check
        server mqtt4 192.168.0.141:3886 check

backend tcp-backend2
       option forwardfor except 127.0.0.1
        balance roundrobin
        mode tcp
        option tcplog
        server mqtt1 192.168.0.126:4883 check
        server mqtt2 192.168.0.126:5883 check
        server mqtt3 192.168.0.126:6883 check
        server mqtt4 192.168.0.126:7883 check
```

---

<div class="post-metadata">

**Author:** ![stefws](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.haproxy.org/stefws/32/439_2.png) [@stefws](https://discourse.haproxy.org/u/stefws)\
**Post date:** [March 30, 2017, 2:20pm UTC](https://discourse.haproxy.org/t/using-multiple-cpu-cores-any-specific-drawback/998/2 "2017-03-30T14:20:12Z")

</div>

> [@jagbir](#):
>
> multi core use is strongly discouraged. We are bit concerned after reading that statement

+1 why discouraged usage of an available feature of haproxy?  
We are also concerned that when we soon needs to load more traffic through our 1.7.3 haproxy, a single process will not to able to handle the traffic (idle pct converting towards zero, is this a sign that a single core can’t keep up on current cpu clock frequency?)  
If so what other alternativ is there then recommended if not using multiple processes on a multiple core server?

How is it with stats when nbproc\>1, are such reported per process (configuration example please both for http and socket stats)?  
Would we then need to collect stats from a socket per process and potentially aggregate such data if desired?