lighthouse/beacon_node/client/src
Paul Hauner 661307dce1 Separate committee subscriptions queue (#3508)
## Issue Addressed

NA

## Proposed Changes

As we've seen on Prater, there seems to be a correlation between these messages

```
WARN Not enough time for a discovery search  subnet_id: ExactSubnet { subnet_id: SubnetId(19), slot: Slot(3742336) }, service: attestation_service
```

... and nodes falling 20-30 slots behind the head for short periods. These nodes are running ~20k Prater validators.

After running some metrics, I can see that the `network_recv` channel is processing ~250k `AttestationSubscribe` messages per minute. It occurred to me that perhaps the `AttestationSubscribe` messages are "washing out" the `SendRequest` and `SendResponse` messages. In this PR I separate the `AttestationSubscribe` and `SyncCommitteeSubscribe` messages into their own queue so the `tokio::select!` in the `NetworkService` can still process the other messages in the `network_recv` channel without necessarily having to clear all the subscription messages first.

~~I've also added filter to the HTTP API to prevent duplicate subscriptions going to the network service.~~

## Additional Info

- Currently being tested on Prater
2022-08-30 05:47:31 +00:00
..
builder.rs Separate committee subscriptions queue (#3508) 2022-08-30 05:47:31 +00:00
config.rs Bump the MSRV to 1.62 and using #[derive(Default)] on enums (#3304) 2022-07-15 07:31:19 +00:00
error.rs Fix clippy warnings (#1385) 2020-07-23 14:18:00 +00:00
lib.rs Rename eth2_libp2p to lighthouse_network (#2702) 2021-10-19 00:30:39 +00:00
metrics.rs Monitoring service api (#2251) 2021-05-26 05:58:41 +00:00
notifier.rs Harden slot notifier against clock drift (#3519) 2022-08-29 14:34:43 +00:00