Warm lambdas could perhaps use persistent connections, but
are reconnecting needlessly when a check or even assumption before publishing would do (perhaps)
are adding listeners to the connection success event: inefficient and noisy (potentially harmful at scale too)
Seems like the listeners are giving away the problem:
08:00:09 Connecting to {'hostname': '****.iot.eu-west-1.amazonaws.com', 'cert_dir': '/var/task/etc/certs', 'port': 8883, 'internal_server_hostname': '192.168.1.9', 'topic_req': 'squeeze-req', 'topic_resp': 'squeeze-resp', 'debug': False}
Connecting to {'hostname': '****.iot.eu-west-1.amazonaws.com', 'cert_dir': '/var/task/etc/certs', 'port': 8883, 'internal_server_hostname': '192.168.1.9', 'topic_req': 'squeeze-req', 'topic_resp': 'squeeze-resp', 'debug': False}
08:00:11 Connected to client to ****.iot.eu-west-1.amazonaws.com:8883. Subscribing to squeeze-resp
08:00:11 Connected to client to ****.iot.eu-west-1.amazonaws.com:8883. Subscribing to squeeze-resp
08:00:11 Connected to client to ****.iot.eu-west-1.amazonaws.com:8883. Subscribing to squeeze-resp
08:00:11 Connected to client to ****.iot.eu-west-1.amazonaws.com:8883. Subscribing to squeeze-resp
08:00:11 Connected to client to ****.iot.eu-west-1.amazonaws.com:8883. Subscribing to squeeze-resp
08:00:11 MQTT/TLS transport to client to ****.iot.eu-west-1.amazonaws.com:8883 initialised. (@QoS (1,))
08:00:11 MQTT/TLS transport to client to ****.iot.eu-west-1.amazonaws.com:8883 initialised. (@QoS (1,))
08:00:11 MQTT/TLS transport to client to ****.iot.eu-west-1.amazonaws.com:8883 initialised. (@QoS (1,))
08:00:11 MQTT/TLS transport to client to ****.iot.eu-west-1.amazonaws.com:8883 initialised. (@QoS (1,))
08:00:11 MQTT/TLS transport to client to ****.iot.eu-west-1.amazonaws.com:8883 initialised. (@QoS (1,))
Warm lambdas could perhaps use persistent connections, but
Seems like the listeners are giving away the problem: