Process events in batches - #39
Conversation
|
This is ready for a look! Inside the PR:
|
|
I added one more fix since batching seemed to slow down sync events. Now in the stubbed Tested on a M1 Air. I got up to 100k events/sec with batches of 100. 🚀 |
|
|
||
| for (const pluginConfig of pluginsToRun.reverse()) { | ||
| if (pluginConfig.vm?.methods?.processEventBatch && returnedEvents.length > 0) { | ||
| const { processEventBatch } = pluginConfig.vm.methods |
There was a problem hiding this comment.
Nit: could be a bit more concise with less lookups if we moved this line one level up (to right below the for (const pluginConfig... line) with optional chaining and in the if just checked for processEventBatch.
There was a problem hiding this comment.
cleaned it up a bit
| // we have processEvent, but not processEventBatch | ||
| if (!__getExported('processEventBatch') && __getExported('processEvent')) { | ||
| exports.processEventBatch = async function processEventBatch (batch, meta) { | ||
| const processEvent = __getExported('processEvent'); | ||
| let waitFor = false | ||
| const processedEvents = batch.map(event => { | ||
| const e = processEvent(event, meta) | ||
| if (e && typeof e.then !== 'undefined') { | ||
| waitFor = true | ||
| } | ||
| return e | ||
| }) | ||
| const response = waitFor ? (await Promise.all(processedEvents)) : processedEvents; | ||
| return response.filter(r => r) | ||
| } | ||
| // we have processEventBatch, but not processEvent |
There was a problem hiding this comment.
Where do we handle the case when there are both processEvent and processEventBatch?
There was a problem hiding this comment.
The user handled it for us in that case. I think it's fine for the user to give both functions (e.g. making custom batching that only works with max 10 events), yet if they want to give just one of the two, the system should still work. Also if they give zero, the system should work... and then just do the plugin differently.
* silence some test logs * admit defeat in the battle with `esModuleInterop` * add basic typescript piscina workers * es module fix * remove rollup and compile directly with typescript * fix fetch import error * make piscina work in jest, dist and dev... run plugins through it * simplify tests * store plugin status on the `server` * config types * not all keys needed * add worker concurrency setting * clean up code * fix test worker code * add a basic benchmark test * refactor test * refactor test utils * support more serialized binary formats * mock jest behind enemy lines * less verbose logs in tests * add test to make sure adding more CPU cores makes plugins faster! * clone objects * add 12 * fix linter's worries * remove extra word * improve display * remove the exact cpu count from the list * add postgres and redis services to github to make tests pass * add ENV to config * add ENV to config * process events test wip * add db:init script * add db:init script to CI * add db:init script * add db:init script to CI * No prepublish on yarn install * processEvents in vm * run plugins on batches of events * tests for batching performance * async processEvent & events * lint * performance test batches * not a dev run * prettier for ts * prettier * remove support for PostHog.capture inside `processEvent` for now. This will go back inside the scheduled/webhook plugins * less round in tests, increase timeout * refactor * slight cleanup * rename `processEvents` to `processEventBatch` * only wait in processEventBatch if needed * Order file extensions more readably in lint-staged * Prettier * remove time rounding * less lookups * describe test devmode * add "light" * Remove redundant Math.round * Run prettier * Fix performance measurement * Prettier but correctly Co-authored-by: Michael Matloka <dev@twixes.com>
Still WIPReady for review (comments below)