V2 vs V3 performance

[EwilsonS]

I recently upgraded to version 3.0.4 . I notice a significant slowdown with any call to the api. Has anyone experienced the same?

[aravindanr]

If you have them, please quantify the claim with some numbers from v2 and v3, and also share the dependencies that you use.

[EwilsonS]

Just to give an idea of my experience, a rest call that usually takes 300 ms to complete is now taking 10s. A 4s workflow is now taking 2mins.

I'm curious if the removal of the jetty server could have any impact or if the noop indexDao is causing a hit on performance, as we are not using an external instance of elasticsearch.

Here are dependencies listed from ./gradlew dependencies

> Configure project :conductor-azureblob-storage
Inferred project: conductor, version: 0.1.0-SNAPSHOT

> Task :dependencies

------------------------------------------------------------
Root project 'conductor' - conductor
------------------------------------------------------------

** Removed **

BUILD SUCCESSFUL in 22s
1 actionable task: 1 executed

[aravindanr]

Sorry for the confusion. I was referring to what data store you are using with Conductor. That's essentially what determines API and workflow latencies. We run Conductor with Cassandra for persistence, Redis for queues and ElasticSearch 6 for index. We haven't noticed any increase in latency with the 3.0 upgrade. I doubt that the switch from Jetty to Tomcat will have an impact on these latency variations that you are noticing. Also, using the NoopIndexDAO should make things faster than using Elasticsearch.

[EwilsonS]

I've been using Sql Server with old and new versions, which I know you do not support yet. I will double check my implementation of mssql. Thanks for the guidance.

[dcore94]

Yes, in particular I noticed this for the start workflow API call which takes sometimes up to tens of seconds causing some read timeouts on the client but then the workflows run correctly. I'm currently not yet aware of any other slowdown. I see that polling for tasks is still acceptable in less than 100ms anyway. Our setup is based on docker stack with dedicated services for postgres and elasticsearch 6.

…

On 23/07/21 22:51, Evan wrote: I recently upgraded to version 3.0.4 . I notice a significant slowdown with any interaction with the api. Has anyone experienced the same? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2372>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMKIMGMQLDCQDKLLGVADDTZHI4HANCNFSM5A4VRQKQ>.

[EwilsonS]

We solve this by increasing our connectionPoolMaxSize from 1 to 10

[dcore94]

Hi Evan, sorry but where do you set this property? Thanks.

…

On 30/07/21 22:26, Evan wrote: We solve this by increasing our |connectionPoolMaxSize| from 1 to 10 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2372 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMKIN2IGSKI4PUDEA2ONDT2MDG5ANCNFSM5A4VRQKQ>.

[EwilsonS]

either application.properties or your PostgresProperties depending on your setup