Time it takes between an envelope be created and being processed

[weemen]

I don't know if this is an issue or not. I'm also relative new to pekko so I cannot fully judge.
Recently I noticed that my projections are slow and I'm figuring out if this default behaviour or not.

So what did I do (and I maybe I'm measure it on the wrong way).
I'm running my app locally on my laptop. (No cluster setup)
My app has one projection active (I disabled all my other projections)
My projection does do a simple insert to postgress (this takes 30ms)
and at the end of the projection handler I do:

val timing             = (System.currentTimeMillis() - envelope.timestamp)

The outcome timing is always in the range 1800ms to 2200ms.

Although we strive for eventual consistency this still seems quite slow to me.
Is this normal? do I messure it in the correct way?

Many thanks in advance

Leon

[pjfanning]

@weemen I'll leave it in this repo but arguably this be in https://github.com/apache/pekko-projection.

I am not an expert on Pekko Projections but I would suggest that if you could provide code snippets and/or more detail on your environment that that might help people to envision the issue.

From download stats, Projections are not one of the most used Pekko features.

[pjfanning]

Thanks @weemen. I don't have the time to really look into this. pekko-projections doesn't have any real community behind it. Most of the effort is on the core Pekko libs and Pekko HTTP. Maybe, someone else will have a look.
One of the reasons I would be reluctant to use a solution like your demo app is that there are so many moving parts and no tidy way to trace what is going on. It is not like old fashioned Java apps where you could get a debugger or a profiler. If you can get this to all work in one JVM, maybe those tools could still prove useful.

OpenTelemetry has some Pekko support and may also be able to instrument the database calls. If we had paid developers and a big budget, we would be instrumenting the code to allow Telemetry tooling to work well with the Pekko libs but even at that, we would start with Actors and Streams and take ages to get around to Persistence and then Projections.

[pjfanning]

Possibly. you could enable debug logging and analysing just one event instead of having many events multiplying the logs. If you have any suggestions for useful logging, please feel free to submit ideas or PRs.

[weemen]

Heey man first of all thank you very much for your quick response!! That's highly appreciated!
Cool let me try that! I'm not so sure if it is the database call itself but my gut feeling feels like that after the event is created that an event might be scheduled for sending to projection handlers. I will also try to dive into the code more to see what is going on.

On my way home today from the office I thought to also create a dummy projection with r2dbc to see if I get the same results.

Again thanks a lot, for everyone else reading this: If you have ideas feel free to dump them here!

[weemen]

Problem resolved: it was configuration!!!

# Pekko Persistence Query provider
jdbc-read-journal {
    use-shared-db = "slick-read-journal"
    refresh-interval = "100ms"
    journal-sequence-retrieval.query-delay = "100ms"
}

Source