High performance impact of server.trackEvent -- let's re-evaluate when it gets called

[jankeromnes]

Bug description

The API method server.trackEvent() is being called too frequently, putting excessive load on our servers.

It would be good to:

• find out which events are tracked the most frequently
• ... re-evaluate whether they're still useful, or if we can stop tracking them
• ... if they're still useful, see if we can send them to our analytics backend (segment) directly instead of routing them through server

server.trackEvent() seems to be called most often by the dashboard and by the IDE backends (both VS Code and JetBrains).

---

From Slack (internal):

trackEvent is by far our most called API method (even beating getWorkspace - and has 2x the callrate of sendHeartbeat 😬 )

It puts considerable load on our server instances.

From Grafana (internal):

Steps to reproduce

1. Look at the API call rates in Grafana

Workspace affected

No response

Expected behavior

No response

Example repository

No response

Anything else?

No response

[AlexTugarev]

I've created a draft (#8388) it doesn't aim to solve this issue entirely, but maybe it already reduces the load significantly enough.

[JanKoehnlein]

@akosyakov was concerned about rate-limits when we send data to segment directly. I don't think 60M events in 10min are a problem yet.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.