Meteor Performance - a TODO list

performance
1

Hi folks,

As everybody knows, we’ve been working hard to improve Meteor’s performance. Recently, @nachocodoner implemented SWC and has also been advancing our RSPack integration.

On my side, I’m working on an upcoming change that will significantly reduce memory usage by replacing the oplog with a Change Streams–based implementation, along with a new EventEmitter-based DDP transport (WIP) that promises replace the pooling. I’m also setting up full OpenTelemetry instrumentation to measure and validate these improvements (more news coming soon!).

Beyond that, we’ve had some interesting discussions around replacing EJSON with CBOR and a PR about a BSON-to-JavaScript transformation approach to in the oplog(maybe in pooling as well, didnt check it)

A few additional points:

  1. There are many opportunities to optimize Meteor’s JavaScript for V8. If you run TOOL_NODE_FLAGS="--trace-deopt" meteor, you’ll see a long list of unoptimized functions we could improve.
  2. I started cleaning up unnecessary Promise overhead (article/ PR)

So I’d like to open this topic by inviting everyone to share ideas on how we can keep improving Meteor’s performance and reducing resource usage.

20 Likes
2

DDP session resumption is an easy performance win:

1 Like
3

Maybe check and revive this PR

Integration with uWebSockets could be very interesting.

1 Like
4

Could the network performance be improved by using Pro instead of sending json data?

5

would be nice to have a benchmark:

  • socketjs(current package used in meteor) vs Uwebsocket
  • Protobuff over ws vs json over ws

[uWebSockets]
A good point about uWebSockets is the fact the sockjs was updated 4y ago vs 3 weeks ago from uWebSockets.

@ignl do you mind to do a small POC?

[Proto]
One advantage of using Protobuf in Meteor is that we’re full-stack, so developers don’t need to worry about Protobuf-specific knowledge. They only need to work with JS/TS types, and we can handle everything behind the scenes.

1 Like
6

I was looking with chatgpt into this some time ago and conclusion was that it’s a big undertaking so stopped right there. uWebsockets are very very very performant, but it’s complete reimplementation with different api, so it’s not really compatible with nodejs ws or socksjs and would require deep refactoring in meteor code. But I don’t really know much about meteor.js internals, maybe it’s not as bad as chatgpt says. I just put this idea out as potentially interesting.
There were also some discussions about maybe moving to bun (and bun I think uses uWebsockets underneath) so if refactor is big anyway maybe that could be a move. Of course this is just brainstorming for now.

7

Protobuf needs to be de-serialized, I am not sure it would be more performant than simple json. I would really research and test this before investing into implementation. Maybe there are some new browser api’s that could do deserialization natively idk, but if done in js it probably won’t give any big wins and introduce complexity.

8

For those who want to work on it, understand DDP pkg could be a good point of start, here and here you can find a guide

@ignl but what do you think to do an benchmark comparing ws, sockjs and uws and talk about the diffenreces between them, it will be a good content for the dev community and for who want to do a poc like this. It will a required knowledge for who want to work on it