tcp - RabbitMQ / MQTT performance -

tcp - RabbitMQ / MQTT performance -

we using rabbitmq/with mqtt adapter broker connect nodes monitoring.

theoretically, beingness tcp based can have max of n connections/interface, having n port, n ~ [5000, 65000]. realize having multiple network interfaces, can theoretically service far more number of connections.

is there sensible limit max number of connections , hence number of nodes can serviced having sane cpu/mem usage pattern.

but, mean maintaining & processing n connections concurrently on commodity hw (quadcore 2ghz/8gb ram). there any:

formal process derive how many connections can serviced.

what system/rabbitmq parameters should @ optimize.

it indicate goverened daemon servicing connections. formal architecture / design constraints (though @ moment sticking rabbitmq).

currently, 30000 connections possible serviced below config, %cpu ~ 100% , memory getting exhausted > 60% throughput of ~ 80 (x300bytes) messages/sec.

hw: i7-3630qm cpu @ 2.40ghz/4 cores/2 threads & 8gb ram. sw: ubuntu/rabbitmq mqtt adapter. **rabbitmq.config** [ {rabbit, [ {tcp_listeners, [5672]}, {loopback_users, []}, {vm_memory_high_watermark, 0.8}, {vm_memory_high_watermark_paging_ratio, 0.75} ] }, {rabbitmq_mqtt, [{default_user, <<"guest">>}, {default_pass, <<"guest">>}, {allow_anonymous, true}, {vhost, <<"/">>}, {exchange, <<"amq.topic">>}, {subscription_ttl, 1800000}, {prefetch, 10}, {ssl_listeners, []}, {tcp_listeners, [1883]}, {tcp_listen_options, [binary, {packet, raw}, {reuseaddr, true}, {backlog, 128}, {nodelay, true}]}]}].

also, feasible retire/evict connections while handing new connections based on policy lru / lfu of cache-eviction. can done @ scheme level (os / tcp layer).

thanks.jb.

tcp rabbitmq mqtt