[Meta] Enabling xpack plugins limits Kibana server capacity

[lizozom]

While benchmarking our server capacity and running a node profiler, we saw that disabling xpack plugins impacts server capacity.

Plainly disabling them increases our server's capacity (how many concurrent requests can we handle) about x2.
Disabling oss plugins does nothing to server capcacity.

I'm currently not sure which plugin is causing this, but it would be easier to troubleshoot if we have #129050

Test Results
Testing instructions

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

@rayafratkina sorry, how exactly is that issue supposed to come under Core's responsibility?

[lizozom]

To clarify, this issue was to show that many plugins register request \ response listeners that effect the response time of static asset delivery.

I think there are several potential solutons to this:

1. Stop serving static assets from the dev server and use a cdn \ separate process
2. Make sure that no custom listeners run on static asset delivery.

If you don't think this is a priority, feel free to close \ defer this 🙏🏻

[lukeelmers]

Stop serving static assets from the dev server and use a cdn

Last time we floated the idea of serving static assets over a CDN, we got strong feedback that this wasn't something we should be pursuing at this time.

Make sure that no custom listeners run on static asset delivery

I'm assuming you're talking about our http lifecycle hooks here? The only plugins I'm aware of which are using those are security/spaces/licensing (all in xpack), and I think we'd still want those to run for static asset delivery. Or maybe there is something else you are referring to by custom listeners?

[lizozom]

@rudolf and I are looking into some potential performance issues.
Now looking at #140514
Lets keep linking any additional work here.

[afharo]

@lizozom I submitted #140763. Can you help me validate if it improves the performance in any way?