Sweep Requests

[mcrumm]

The Requests table should be periodically "swept" to manage memory usage.

Considering #38, if the configuration lives on the endpoint, then we will need to decide when to start the sweep. Here are my ideas:

1. Start the sweep after the first request.
2. Add an endpoints: [atom(), ...] option to the config :phoenix_profiler and pull the configs when the Requests process starts.

For 1)

Pro: Zero config for endpoint discovery. No unnecessary sweeps.

Cons: Config validation also has to wait for the first request. Special logging required for bad configs?

For 2)

Pros: Config validation happens on Application start.
Cons: Additional config for endpoint discovery. Split configuration for the profiler.

I am leaning towards 1) but I open to other thoughts as well :)

As for the configuration, wherever it lives, I was thinking of this:

  requests_expire_after: :timer.hours(24), # how long until requests expire (in milliseconds).
  requests_sweep_interval: :timer.seconds(600) # how often to sweep in milliseconds.

[leandrocp]

I'm 👍🏻 for option 1, more explicit and less install steps to do.

Special logging required for bad configs?

We could leverage https://github.com/dashbitco/nimble_options although pulling an extra lib seems a bit overkill at this moment.

[mcrumm]

I think I am really asking what should happen at runtime if the profiler config on the endpoint is invalid? 🤔

[leandrocp]

I think I am really asking what should happen at runtime if the profiler config on the endpoint is invalid? 🤔

Disable it and display a warning? I mean, it shouldn't affect the host app and it's a tool made for developers so it should be straightforward to spot it's not working just by looking at logs/console and then fix it (the config is just a few keys to check/change). In other words, don't get in the way if something is wrong.

Unless you see a scenario where it would break or something (in the case if I'm missing something out 😅)