search

clicon / clixon

YANG-based toolchain including NETCONF and RESTCONF interfaces and an interactive CLI
http://www.clicon.org/
Other
215 stars 72 forks source link

Does the latest release support concurrent responses for multi restconf request at same time? #346

Open magicalfox007 opened 2 years ago

magicalfox007 commented 2 years ago

I use clixon-4.2.0 to implement a restconf server, but it seems that it can't handle multi restconf request (e.g GET or POST) at same time.

olofhagsand commented 2 years ago

I assume your 4.2 usage is based on Nginx/fcgi, since native restconf was introduced in 4.6. The fcgi solution serializes requests from the reverse proxy. In general, multiple requests are serialized and should be processed one after the other. The "serialization points" are somewhat different in different versions, I am not 100% sure on the 4.2 behavior. The backend itself serializes requests using run-to-completion before the next request is processed. In the fcgi solution, I think the restconf daemon also does the same, but using a "listen" queue, which should buffer incoming requests. In what way do you experience that multiple restconf requests cannot be processed "at the same time"? Are requests dropped, or blocked?

magicalfox007 commented 2 years ago

Thanks for reply. I do use Ngnix/fcgi as reverse proxy. I use postman to build serveral get/post requests to obtain status data: ( assue number of requests is N)

So if it is just like this, I would like to ask whether the lastest release has better performance ?

olofhagsand commented 2 years ago

I think the fcgi variant has the same behavior in 5.7.0. The native implementation has still the same backend run-to-completion sequencer. However: 1) the latency chain is shorter, where fcgi has: client -- nginx -- clixon_restconf - clixon_backend, native has: client - clixon_restconf -- clixon_backend. I.e., one step shorter. 2) Native clixon_restconf process several request "at once", ie if one session waits for the backend, another session can be accepted. This is done by "select" interleaving, ie not true concurrency. The second still has to wait for the backend to complete though.