# Netconf server performance

**URL:** <https://dmap-community.ductus.global/t/netconf-server-performance/2802>\
**Category:** NETCONF\
**Created:** [November 23, 2019, 4:46am UTC](https://dmap-community.ductus.global/t/netconf-server-performance/2802 "2019-11-23T04:46:48Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![HoangCV](https://avatars.discourse-cdn.com/v4/letter/h/ce7236/32.png) [@HoangCV](https://dmap-community.ductus.global/u/HoangCV)\
**Post date:** [November 23, 2019, 4:46am UTC](https://dmap-community.ductus.global/t/netconf-server-performance/2802/1 "2019-11-23T04:46:48Z")

</div>

Hi everyone, I am in the process of testing the performance of netconf-server, I am a little worried, I first run confd on the server and load the yang model, then I simulate 100 netconf- client on the client, as a result, only more than 1,000 connections are established and the server is down. I expect about 10,000 connections. The reason is why?  
(My server: Xeon 64 CPUs, RAM 256 GB, i’m using confd-base)

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [November 23, 2019, 3:49pm UTC](https://dmap-community.ductus.global/t/netconf-server-performance/2802/2 "2019-11-23T15:49:35Z")

</div>

There should be some indication in the confd.log of why ConfD went down. Based on what you’re doing and the numbers, I would guess that it’s “Out of file descriptors for accept() - process limit reached”, since the default per-process limit on open file descriptors on Linux is 1024. You can raise that number with `ulimit`, e.g. `ulimit -n 8192`, in the shell where you start ConfD.

That said, I have to wonder what your use case is. The NETCONF protocol was designed for a management application - the client - to manage (network) devices - where the server runs. It’s not uncommon for a manager to manage hundreds or even thousands of devices, but the idea of 100 managers managing a single device is quite, um… - strange. And even so, why would they need 100 connections each to do it, one should be enough - the SSH transport provides for multiple channels, each corresponding to a NETCONF session, on a single TCP connection.

---

<div class="post-metadata">

**Author:** ![HoangCV](https://avatars.discourse-cdn.com/v4/letter/h/ce7236/32.png) [@HoangCV](https://dmap-community.ductus.global/u/HoangCV)\
**Post date:** [November 25, 2019, 9:09am UTC](https://dmap-community.ductus.global/t/netconf-server-performance/2802/3 "2019-11-25T09:09:08Z")

</div>

Thank per, it’s working. I plan to design netconf-server in the management application so that the devices can synchronize configuration data with management application. Is that okay? is there any other way?

---

<div class="post-metadata">

**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\
**Post date:** [November 25, 2019, 3:07pm UTC](https://dmap-community.ductus.global/t/netconf-server-performance/2802/4 "2019-11-25T15:07:55Z")

</div>

How would the devices sync the config with the mgmt application?  
What does sync mean here?

Normally ConfD (NETCONF server) sits on the device that is managed over NETCONF by a manager (NETCONF client).