[Mongo] optimizations

[mishig25]

Mongo optimizations

1. remove duplicated assistants query. Read this comment
2. limit conversations to last 300 c862458

[mishig25]

with this change, it is possible to re-use the results from collections.assistants.find query below & completely remove the query being done in src/routes/settings/+layout.server.ts

cc: @nsarrazin is this change good?

[mishig25]

the change is: getting all the assistants of a user, instead of only ones user has conversation with

[coyotte508]

but a user can delete assistants from their list, see "Remove" link

[mishig25]

could you elaborate on what's expected behavior?

[coyotte508]

we need all assistants for conversations in order to compute their avatarHash below:

				avatarHash:
					conv.assistantId &&
					assistants.find((a) => a._id.toString() === conv.assistantId?.toString())?.avatar,

If a user removes an assistant from their settings, with this PR, the avatar of the assitant won't show up in the conversation list next to the conversation title. Eg julien's avatar wouldn't show here:

(if I removed him in my settings)

[coyotte508]

You can still do this:

Suggested change

	const assistantIds = settings?.assistants?.map((assistantId) => assistantId) ?? [];
	const assistantIds = [
	...(settings?.assistants?.map((assistantId) => assistantId) ?? []),
	...conversations.map(conv => conv.assistantId)
	];

[mishig25]

handled in 07bd2d1

[coyotte508]

Suggested change

	.toArray();
	.limit(100)
	.toArray();

Maybe another optimization to do?

[mishig25]

applied the change. Will implement pagination for conversation in a subsequent PR

[coyotte508]

You can still do this:

Suggested change

	const assistantIds = settings?.assistants?.map((assistantId) => assistantId) ?? [];
	const assistantIds = [
	...(settings?.assistants?.map((assistantId) => assistantId) ?? []),
	...conversations.map(conv => conv.assistantId)
	];

[nsarrazin]

Looks good now!

[coyotte508]

We should probably add some monitoring at some point

eg create a timeseries collection (we can add a TTL index to it too) with url, method, timestamps, user / session id, and time taken for different parts of the code (just the +layout.server.ts's load at the start)

Then we can calculate stats like p50/p90/p99 and also see if the slow times are triggered by specific users or urls/parts of the code

[zacps]

We should probably add some monitoring at some point

Could be addressed by #692, I think everyone is kind of standardising around opentelemetry at the moment so that would be my vote.