if data index was supposed to provide snapshot view of the process instance… why do we keep it after the process instance is finished?
On Mon, Feb 19, 2024 at 7:12 AM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Martin. > After taking a deeper look at this, I realize that the behaviour is the > expected one. > Runtimes DB does not track the completed process instance (that's what the > JDBCProcessInstances warn is telling us), but DataIndex, as expected, is > tracking it in processes and nodes table. And yes it will grow over time. > What we need is some configurable purge mechanism for DataIndex, so it > eventually removes older completed process instances. > > On Tue, Feb 13, 2024 at 12:59 PM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Hi Martin, > > Good catch!. Looks like the skipping performed for process instances is > > not applied to node instances. Something we definitely need to review on > > the runtimes side. > > > > On Mon, Feb 12, 2024 at 11:59 PM Martin Weiler <mwei...@ibm.com.invalid> > > wrote: > > > >> On a somewhat related note, testing a simple workflow (start -> script > >> node -> end), I see the following messages in the logs: > >> 2024-02-12 22:49:50,493 28758dde544c WARN > >> [org.kie.kogito.persistence.jdbc.JDBCProcessInstances:-1] > >> (executor-thread-3) Skipping create of process instance id: > >> 7083088e-b899-47cb-b85c-5d9ccb0aa166, state: 2 > >> > >> So far, so good. And I'd expect to see no trace of this process in the > >> database if I don't have data audit enabled. > >> > >> However, the 'processes' table contains a row with state=2, with related > >> entries in the 'nodes' table. In a load test, I see these tables grow > >> significantly over time. Am I missing something to have these entries > >> cleaned up automatically? > >> > >> ________________________________________ > >> From: Martin Weiler <mwei...@ibm.com.INVALID> > >> Sent: Monday, February 12, 2024 3:40 PM > >> To: dev@kie.apache.org > >> Subject: [EXTERNAL] RE: [DISCUSSION] Performance issues with data-index > >> persistence addon > >> > >> Thanks everyone for your input. Based on this discussion, I opened the > >> following PR: > >> https://github.com/apache/incubator-kie-kogito-apps/pull/1985 > >> > >> With this change, the performance seems to be stable over time: > >> > >> > https://drive.google.com/file/d/1zkullvfrJpRp7TRjxDa41ok6kEIR7Fty/view?usp=sharing > >> > >> Martin > >> > >> ________________________________________ > >> From: Gonzalo Muñoz <gmuno...@apache.org> > >> Sent: Friday, February 9, 2024 9:42 AM > >> To: dev@kie.apache.org > >> Subject: [EXTERNAL] Re: [DISCUSSION] Performance issues with data-index > >> persistence addon > >> > >> Great work Francisco, > >> Martin, take a look at this link with some related tips (in case you > find > >> it useful): > >> https://www.cybertec-postgresql.com/en/index-your-foreign-key/ > >> > >> El vie, 9 feb 2024 a las 17:20, Francisco Javier Tirado Sarti (< > >> ftira...@redhat.com>) escribió: > >> > >> > For the moment being, we will keep JPA till we exhaust all > >> possibilities, > >> > let's call switching from jpa to jdbc our hidden plan B ;) > >> > I already told Martin, but in order everyone to know, just after > writing > >> > the previous email, I thought "what if Postgres is not automatically > >> > indexing foreign keys like mysql?" and, eureka > >> > Postgres doc > >> > https://www.postgresql.org/docs/current/ddl-constraints.html > >> > Mysql doc > >> > https://dev.mysql.com/doc/refman/8.0/en/constraint-foreign-key.html > >> > These are the relevant excerpt > >> > > >> > *Postgresql* > >> > *A foreign key must reference columns that either are a primary key or > >> form > >> > a unique constraint, or are columns from a non-partial unique index. > >> This > >> > means that the referenced columns always have an index to allow > >> efficient > >> > lookups on whether a referencing row has a match. Since a DELETE of a > >> row > >> > from the referenced table or an UPDATE of a referenced column will > >> require > >> > a scan of the referencing table for rows matching the old value, it is > >> > often a good idea to index the referencing columns too. Because this > is > >> not > >> > always needed, and there are many choices available on how to index, > the > >> > declaration of a foreign key constraint does not automatically create > an > >> > index on the referencing columns.* > >> > *Mysql* > >> > *MySQL requires that foreign key columns be indexed; if you create a > >> table > >> > with a foreign key constraint but no index on a given column, an index > >> is > >> > created. * > >> > > >> > So I asked Martin to especially create an index for > process_instance_id > >> > column on nodes table > >> > I think that will fix the problem detected on the thread dump. > >> > The simpler process test to verify queries are fine still stands, > >> though ;) > >> > > >> > > >> > On Fri, Feb 9, 2024 at 5:10 PM Tibor Zimányi <tzima...@apache.org> > >> wrote: > >> > > >> > > I always preferred pure JDBC over Hibernate myself, just for the > sake > >> of > >> > > control of what is happening :) So I would not -1 that myself. > >> > > > >> > > Tibor > >> > > > >> > > Dňa pi 9. 2. 2024, 17:00 Francisco Javier Tirado Sarti < > >> > > ftira...@redhat.com> > >> > > napísal(a): > >> > > > >> > > > Hi, > >> > > > Usually I do not want to talk about work in progress because > >> > preliminary > >> > > > conclusions are pretty volatile but, well, there are a couple of > >> things > >> > > > that can be concluded from the really valuable information that > >> Martin > >> > > > provided. > >> > > > 1) In order to be able to determine if the number of statements is > >> > larger > >> > > > than expected, I asked Martin to test with a simpler process > >> > definition. > >> > > > One with just three nodes: start, script and end. The script one > >> should > >> > > > change just one variable. This way we can analyze if the number of > >> > > queries > >> > > > is the expected one. From the single log (audit was activated > them) > >> my > >> > > > conclusion is that the number of insert/updates over processes and > >> > nodes > >> > > > (there a lot over task, that I will prefer to skip for now, baby > >> steps) > >> > > is > >> > > > the expected one. > >> > > > 2) Analysing the thread dump, we see around 15 threads executing > >> this > >> > > line > >> > > > at > >> > > > > >> > > > > >> > > > >> > > >> > org.kie.kogito.index.jpa.storage.ProcessInstanceEntityStorage.indexNode(ProcessInstanceEntityStorage.java:125), > >> > > > so its pretty clear the code to be optimized ;). I'm evaluating > >> > > > possibilities within JPA/Hibernate, but I'm starting to think that > >> it > >> > > might > >> > > > be better to switch to JDBC and skip hibernate. Our lives will be > >> > > simpler, > >> > > > especially with a schema relatively simple like ours (that will be > >> my > >> > > > recommendation if I was an external consultant) > >> > > > > >> > > > On Fri, Feb 9, 2024 at 4:15 PM Tibor Zimányi <tzima...@apache.org > > > >> > > wrote: > >> > > > > >> > > > > Hi, > >> > > > > > >> > > > > this will be a bit off-topic. However as far as performance, I > >> think > >> > we > >> > > > > should think about that we have string primary keys (IDs). I > would > >> > > expect > >> > > > > the database systems are much better with indexing numeric keys > >> than > >> > > > > strings. I remember from the past, when I was working with DBs, > >> that > >> > > > using > >> > > > > strings as keys or indexes was a discouraged practice. > >> > > > > > >> > > > > Best regards, > >> > > > > Tibor > >> > > > > > >> > > > > Dňa št 8. 2. 2024, 22:45 Martin Weiler <mwei...@ibm.com.invalid > > > >> > > > > napísal(a): > >> > > > > > >> > > > > > I changed the test to use MongoDB [1] and I don't see a > >> performance > >> > > > > > degradation with this setup [2]. > >> > > > > > > >> > > > > > Please keep us posted of your findings. Thanks! > >> > > > > > > >> > > > > > Martin > >> > > > > > > >> > > > > > [1] > >> > > > > > >> > > https://github.com/martinweiler/job-service-refactor-test/tree/mongodb > >> > > > > > [2] > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://drive.google.com/file/d/1NfacXaxJlgRMw4OQ5S20cvkzvaUKUVFj/view?usp=sharing > >> > > > > > > >> > > > > > ________________________________________ > >> > > > > > From: Francisco Javier Tirado Sarti <ftira...@redhat.com> > >> > > > > > Sent: Wednesday, February 7, 2024 11:40 AM > >> > > > > > To: dev@kie.apache.org > >> > > > > > Subject: [EXTERNAL] Re: [DISCUSSION] Performance issues with > >> > > data-index > >> > > > > > persistence addon > >> > > > > > > >> > > > > > yes, it can be index degradation because of size, but I > believe > >> (I > >> > > > might > >> > > > > be > >> > > > > > wrong) the db is too small (yet) for that. > >> > > > > > But, eventually, Postgres, when the DB is huge enough, > >> unavoidably > >> > > will > >> > > > > > behave like the graphic that Martin sent. > >> > > > > > Since I believe we are not huge enough (yet), lets rule out > >> another > >> > > > issue > >> > > > > > by analysing the sql logs (I requested those to Martin offline > >> and > >> > he > >> > > > is > >> > > > > > going to kindly collect them). > >> > > > > > Also Im curious to know if Mongo behave in the same way. > >> > > > > > > >> > > > > > On Wed, Feb 7, 2024 at 7:25 PM Enrique Gonzalez Martinez < > >> > > > > > egonza...@apache.org> wrote: > >> > > > > > > >> > > > > > > Hi Francisco, > >> > > > > > > I would highly recommend to check indexes and how the > updates > >> > work > >> > > in > >> > > > > > data > >> > > > > > > index to avoid full scan table and lock the full table. Some > >> db > >> > are > >> > > > > very > >> > > > > > > sensitive to that. > >> > > > > > > > >> > > > > > > El mié, 7 feb 2024, 18:41, Francisco Javier Tirado Sarti < > >> > > > > > > ftira...@redhat.com> escribió: > >> > > > > > > > >> > > > > > > > Hi Martin, > >> > > > > > > > While I analyze the data, let me ask you if it is possible > >> to > >> > > > perform > >> > > > > > > > another check (similar in a way to disabling data-index > like > >> > you > >> > > > do) > >> > > > > > Can > >> > > > > > > > you switch to MongoDB persistence and check if the same > >> > > degradation > >> > > > > > that > >> > > > > > > is > >> > > > > > > > there for postgres remains? > >> > > > > > > > I do not know if this is feasible but will certainly > >> indicate > >> > the > >> > > > > > problem > >> > > > > > > > is on the postgres storage layer and I do not have a clear > >> > > > prediction > >> > > > > > of > >> > > > > > > > what we will see when doing this switch. > >> > > > > > > > > >> > > > > > > > On Wed, Feb 7, 2024 at 6:37 PM Martin Weiler > >> > > > <mwei...@ibm.com.invalid > >> > > > > > > >> > > > > > > > wrote: > >> > > > > > > > > >> > > > > > > > > Hi Francisco, > >> > > > > > > > > > >> > > > > > > > > thanks for your work on this important topic! > >> > > > > > > > > > >> > > > > > > > > I would like to share some test results here, which > might > >> > help > >> > > to > >> > > > > > > improve > >> > > > > > > > > the codebase even further. I am using the jmeter based > >> test > >> > > case > >> > > > > from > >> > > > > > > > Pere > >> > > > > > > > > and Enrique (thanks guys!) [1] which uses a load of 30 > >> > threads > >> > > to > >> > > > > > > > > > >> > > > > > > > > 1) start a new process instance (POST) > >> > > > > > > > > 2) retrieve tasks for a user (GET) > >> > > > > > > > > 3) fetches task details (GET) > >> > > > > > > > > 4) complete a task (POST) > >> > > > > > > > > 5) execute a query on data-audit > >> > > > > > > > > > >> > > > > > > > > With this test setup, I noticed that the performance for > >> the > >> > > POST > >> > > > > > > > > requests, in particular the one to start a new process > >> > > instance, > >> > > > > > > degrades > >> > > > > > > > > over time - see graph [2]. If I run the same test > without > >> > > > > data-index, > >> > > > > > > > then > >> > > > > > > > > there is no such performance degradation [3]. You can > >> find a > >> > > > thread > >> > > > > > > dump > >> > > > > > > > > captured a few minutes into the first test here [4] that > >> > might > >> > > > help > >> > > > > > to > >> > > > > > > > see > >> > > > > > > > > some of the contention points. > >> > > > > > > > > > >> > > > > > > > > I'd appreciate if you could take a look and see if there > >> is > >> > > > > something > >> > > > > > > > that > >> > > > > > > > > can be further improved based on your previous work. If > >> you > >> > > need > >> > > > > any > >> > > > > > > > > additional data, let me know, but otherwise it is > >> > > straightforward > >> > > > > to > >> > > > > > > run > >> > > > > > > > > the jmeter test as well. > >> > > > > > > > > > >> > > > > > > > > Thanks, > >> > > > > > > > > Martin > >> > > > > > > > > > >> > > > > > > > > [1] > >> https://github.com/pefernan/job-service-refactor-test/ > >> > > > > > > > > [2] > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://drive.google.com/file/d/1Gqn-ixE05kXv2jdssAUlnMuUVcHxIYZ0/view?usp=sharing > >> > > > > > > > > [3] > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://drive.google.com/file/d/10gVNyb4JYg_bA18bNhY9dEDbPn3TOxL7/view?usp=sharing > >> > > > > > > > > [4] > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://drive.google.com/file/d/1jVrtsO49gCvUlnaC9AUAtkVKTm4PbdUv/view?usp=sharing > >> > > > > > > > > > >> > > > > > > > > ________________________________________ > >> > > > > > > > > From: Francisco Javier Tirado Sarti < > ftira...@redhat.com> > >> > > > > > > > > Sent: Wednesday, January 17, 2024 9:13 AM > >> > > > > > > > > To: dev@kie.apache.org > >> > > > > > > > > Cc: Pere Fernandez Perez > >> > > > > > > > > Subject: [EXTERNAL] Re: [DISCUSSION] Performance issues > >> with > >> > > > > > data-index > >> > > > > > > > > persistence addon > >> > > > > > > > > > >> > > > > > > > > Hi Alex, > >> > > > > > > > > I did not take times (which depends on a number of > >> variables > >> > > that > >> > > > > > > > > drastically change between environments), but verify > that > >> the > >> > > > > number > >> > > > > > of > >> > > > > > > > > updates has been reduced drastically without losing > >> > > > functionality, > >> > > > > > > which > >> > > > > > > > is > >> > > > > > > > > objectively a good thing. If before the change, for > every > >> > node > >> > > > > > > executed, > >> > > > > > > > we > >> > > > > > > > > have an update for every node previously executed, so > if a > >> > > > process > >> > > > > > have > >> > > > > > > > 50 > >> > > > > > > > > nodes to execute, we were performing nearly 50*51/2 > >> updates, > >> > > > which > >> > > > > > > gives > >> > > > > > > > us > >> > > > > > > > > a total of 1275 updates, now we have just one for every > >> node > >> > > > being > >> > > > > > > > > executed, implying a total of 50 updates. > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > On Wed, Jan 17, 2024 at 3:18 PM Alex Porcelli < > >> > > a...@porcelli.me> > >> > > > > > > wrote: > >> > > > > > > > > > >> > > > > > > > > > Francisco, > >> > > > > > > > > > > >> > > > > > > > > > I noticed that your PR has been merged, but I was > >> expecting > >> > > (at > >> > > > > > least > >> > > > > > > > > > was my understanding from this thread) that before > >> merging > >> > > some > >> > > > > > > > > > benchmark data would be shared in advance - to assess > >> the > >> > > > > > > cost/benefit > >> > > > > > > > > > of such a decent size change. > >> > > > > > > > > > > >> > > > > > > > > > Do you have any information to share? > >> > > > > > > > > > > >> > > > > > > > > > On Sat, Dec 23, 2023 at 4:02 AM Francisco Javier > Tirado > >> > Sarti > >> > > > > > > > > > <ftira...@redhat.com> wrote: > >> > > > > > > > > > > > >> > > > > > > > > > > Yes, as intended, now we have one select and one > >> > > > insert/update > >> > > > > > per > >> > > > > > > > node > >> > > > > > > > > > > event. > >> > > > > > > > > > > I moved the PR as ready for review and give @Pere > >> > Fernandez > >> > > > > Perez > >> > > > > > > > > > > <pefer...@redhat.com> permission to the branch so > he > >> can > >> > > > edit > >> > > > > it > >> > > > > > > in > >> > > > > > > > > the > >> > > > > > > > > > > next two weeks (Ill be on PTO) if desired, before > >> > merging. > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > On Thu, Dec 21, 2023 at 5:58 PM Alex Porcelli < > >> > > > > a...@porcelli.me> > >> > > > > > > > > wrote: > >> > > > > > > > > > > > >> > > > > > > > > > > > Cool, thank you Francisco! > >> > > > > > > > > > > > > >> > > > > > > > > > > > Did you manage to get some preliminary data about > >> > > > > improvements? > >> > > > > > > > > > > > > >> > > > > > > > > > > > On Thu, Dec 21, 2023 at 11:52 AM Francisco Javier > >> > Tirado > >> > > > > Sarti > >> > > > > > > > > > > > <ftira...@redhat.com> wrote: > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > Yes, after some delay because of quarkus 3 > >> migration. > >> > > Im > >> > > > > > > refining > >> > > > > > > > > > this > >> > > > > > > > > > > > > draft PR > >> > > > > > > > > > > > > > >> > > > > > https://github.com/apache/incubator-kie-kogito-apps/pull/1941 > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > On Thu, Dec 21, 2023 at 5:48 PM Alex Porcelli < > >> > > > > > > a...@porcelli.me> > >> > > > > > > > > > wrote: > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > Any update or new findings on this topic? > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > On Tue, Nov 28, 2023 at 8:38 AM Francisco > Javier > >> > > Tirado > >> > > > > > Sarti > >> > > > > > > > > > > > > > <ftira...@redhat.com> wrote: > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > Hi Alex, > >> > > > > > > > > > > > > > > After considering different options to > improve > >> > > > > > performance, > >> > > > > > > > we > >> > > > > > > > > > feel > >> > > > > > > > > > > > that > >> > > > > > > > > > > > > > it > >> > > > > > > > > > > > > > > is time to "partially" move away from the > >> current > >> > > Map > >> > > > > > style > >> > > > > > > > > > > > interface ( > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://github.com/apache/incubator-kie-kogito-apps/blob/main/persistence-commons/persistence-commons-api/src/main/java/org/kie/kogito/persistence/api/Storage.java > >> > > > > > > > > > > > > > ) > >> > > > > > > > > > > > > > > which was shared with Trusty, to one more > >> > suitable > >> > > > for > >> > > > > > > usage > >> > > > > > > > > > with a > >> > > > > > > > > > > > > > > relational DB like postgresql (but still > >> > compatible > >> > > > > with > >> > > > > > > big > >> > > > > > > > > > table > >> > > > > > > > > > > > dbs). > >> > > > > > > > > > > > > > > The idea will be to replace generic Storage > >> > > interface > >> > > > > by > >> > > > > > > four > >> > > > > > > > > > > > specific > >> > > > > > > > > > > > > > > interfaces (which will inherit from a common > >> one > >> > > that > >> > > > > > keeps > >> > > > > > > > the > >> > > > > > > > > > query > >> > > > > > > > > > > > > > part > >> > > > > > > > > > > > > > > at is it. with get and query methods), that > >> will > >> > > > > include > >> > > > > > > the > >> > > > > > > > > > required > >> > > > > > > > > > > > > > > modification operations for the four > DataIndex > >> > > > > "domains": > >> > > > > > > > > > > > > > processinstance, > >> > > > > > > > > > > > > > > usertask, processdefinitions and jobs. Those > >> > > > interfaces > >> > > > > > > will > >> > > > > > > > > > define > >> > > > > > > > > > > > > > methods > >> > > > > > > > > > > > > > > like addNode, addVariable, updateTask, > >> > > > > addAttachment..... > >> > > > > > > > that > >> > > > > > > > > > will > >> > > > > > > > > > > > allow > >> > > > > > > > > > > > > > > the persistent layer implementation to just > >> > update > >> > > > the > >> > > > > > > > needed > >> > > > > > > > > > info > >> > > > > > > > > > > > in > >> > > > > > > > > > > > > > the > >> > > > > > > > > > > > > > > DB (for example, for addNode in Postgres, > >> just > >> > > > insert > >> > > > > a > >> > > > > > > row > >> > > > > > > > > into > >> > > > > > > > > > > > nodes > >> > > > > > > > > > > > > > > table, for addNode in Mongo, basically the > >> same > >> > > > atomic > >> > > > > > > upsert > >> > > > > > > > > > > > operation > >> > > > > > > > > > > > > > > that is currently done). Therefore, we > >> increase > >> > > > > > performance > >> > > > > > > > for > >> > > > > > > > > > > > Postgres > >> > > > > > > > > > > > > > > and keep the current one for Mongo. The > >> current > >> > DB > >> > > > > > schemas > >> > > > > > > > > won't > >> > > > > > > > > > be > >> > > > > > > > > > > > > > > touched. > >> > > > > > > > > > > > > > > Since the code change is large, I do not > think > >> > I'll > >> > > > be > >> > > > > > able > >> > > > > > > > to > >> > > > > > > > > > have > >> > > > > > > > > > > > the > >> > > > > > > > > > > > > > PR > >> > > > > > > > > > > > > > > ready till next week. > >> > > > > > > > > > > > > > > But before starting, please let me know if > >> that > >> > > > > approach > >> > > > > > is > >> > > > > > > > > fine > >> > > > > > > > > > for > >> > > > > > > > > > > > you. > >> > > > > > > > > > > > > > > Best regards. > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 6:55 PM Alex > Porcelli > >> < > >> > > > > > > > > a...@porcelli.me> > >> > > > > > > > > > > > wrote: > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > Thank you Francisco to getting deeper on > >> this… > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > Looking forward to see the results of your > >> > > > suggested > >> > > > > > > > > > improvements. > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 9:40 AM Francisco > >> > Javier > >> > > > > Tirado > >> > > > > > > > > Sarti < > >> > > > > > > > > > > > > > > > ftira...@redhat.com> wrote: > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > I forgot to attach the queries > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 3:04 PM > Francisco > >> > > Javier > >> > > > > > Tirado > >> > > > > > > > > > Sarti < > >> > > > > > > > > > > > > > > > > ftira...@redhat.com> wrote: > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> Hi, > >> > > > > > > > > > > > > > > > >> A brief update on this topic. > >> > > > > > > > > > > > > > > > >> After doing a simple test with example > >> > > > > > > > > > > > > > > > >> > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://github.com/apache/incubator-kie-kogito-examples/tree/stable/serverless-workflow-examples/serverless-workflow-data-index-quarkus > >> > > > > > > > > > > > > > > > , > >> > > > > > > > > > > > > > > > >> the number of updates over Nodes table > is > >> > n*n, > >> > > > so > >> > > > > we > >> > > > > > > > > manage > >> > > > > > > > > > to > >> > > > > > > > > > > > > > obtain a > >> > > > > > > > > > > > > > > > >> perfect quadratic performance > >> degradation. > >> > The > >> > > > > > problem > >> > > > > > > > is > >> > > > > > > > > > worse > >> > > > > > > > > > > > in > >> > > > > > > > > > > > > > the > >> > > > > > > > > > > > > > > > case > >> > > > > > > > > > > > > > > > >> of Serverless Workflow than in BPMN > >> because > >> > we > >> > > > the > >> > > > > > > > number > >> > > > > > > > > of > >> > > > > > > > > > > > nodes > >> > > > > > > > > > > > > > is > >> > > > > > > > > > > > > > > > >> greater than the number of states. In > >> that > >> > > > > example N > >> > > > > > > is > >> > > > > > > > > 16, > >> > > > > > > > > > but > >> > > > > > > > > > > > for > >> > > > > > > > > > > > > > a > >> > > > > > > > > > > > > > > > more > >> > > > > > > > > > > > > > > > >> complex workflow it would be certainly > >> > large. > >> > > > > > > > > > > > > > > > >> I think that this is more related to > how > >> we > >> > > are > >> > > > > > > handling > >> > > > > > > > > > JPA in > >> > > > > > > > > > > > the > >> > > > > > > > > > > > > > > > code, > >> > > > > > > > > > > > > > > > >> in particular the mapping from model to > >> > entity > >> > > > > > > > (basically > >> > > > > > > > > > JPA is > >> > > > > > > > > > > > > > blind > >> > > > > > > > > > > > > > > > and > >> > > > > > > > > > > > > > > > >> has to update all nodes for every write > >> > > because > >> > > > it > >> > > > > > > > > believes > >> > > > > > > > > > the > >> > > > > > > > > > > > > > node has > >> > > > > > > > > > > > > > > > >> been updated, although it is not) than > an > >> > > issue > >> > > > in > >> > > > > > the > >> > > > > > > > > table > >> > > > > > > > > > > > > > definition. > >> > > > > > > > > > > > > > > > >> In fact, when using JPA, separating the > >> > server > >> > > > > model > >> > > > > > > > from > >> > > > > > > > > > the > >> > > > > > > > > > > > JPA > >> > > > > > > > > > > > > > > > entity is > >> > > > > > > > > > > > > > > > >> not a good idea, especially if the > entity > >> > > > contains > >> > > > > > > > > > collections. > >> > > > > > > > > > > > I > >> > > > > > > > > > > > > > will > >> > > > > > > > > > > > > > > > try > >> > > > > > > > > > > > > > > > >> to change that without breaking > anything. > >> > > > > > > > > > > > > > > > >> > >> > > > > > > > > > > > > > > > >> On Wed, Nov 22, 2023 at 12:10 PM > Enrique > >> > > > Gonzalez > >> > > > > > > > > Martinez < > >> > > > > > > > > > > > > > > > >> egonza...@apache.org> wrote: > >> > > > > > > > > > > > > > > > >> > >> > > > > > > > > > > > > > > > >>> After the events split you now will > >> need to > >> > > > > create > >> > > > > > a > >> > > > > > > > node > >> > > > > > > > > > > > instance > >> > > > > > > > > > > > > > > > >>> model instance of making independent > >> from > >> > the > >> > > > > > process > >> > > > > > > > > > instance. > >> > > > > > > > > > > > > > > > >>> That should do the trick. > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > > > > >>> Regarding deleting/inserting it was > >> fixed > >> > at > >> > > > some > >> > > > > > > > point. > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > > > > >>> El mar, 21 nov 2023 a las 20:22, > >> Francisco > >> > > > Javier > >> > > > > > > > Tirado > >> > > > > > > > > > Sarti > >> > > > > > > > > > > > > > > > >>> (<ftira...@redhat.com>) escribió: > >> > > > > > > > > > > > > > > > >>> > > >> > > > > > > > > > > > > > > > >>> > Hi Martin, > >> > > > > > > > > > > > > > > > >>> > I have a task to review performance > of > >> > > > > > > > > > > > > > > > >>> > > >> > > > > > > > > > > > > > > > >>> > ProcessInstanceNodeDataEventMerger > >> > > > > > > > > > > > > > > > >>> > My idea is to reduce the number of > >> delete > >> > > > > inserts > >> > > > > > > > when > >> > > > > > > > > > > > processing > >> > > > > > > > > > > > > > > > >>> events > >> > > > > > > > > > > > > > > > >>> > and try to do it incremental. > >> > > > > > > > > > > > > > > > >>> > That should improve performance. > >> > > > > > > > > > > > > > > > >>> > PS: > >> > > > > > > > > > > > > > > > >>> > I was planning to send an e-mail > >> tomorrow > >> > > > > > > announcing > >> > > > > > > > > > that in > >> > > > > > > > > > > > > > case you > >> > > > > > > > > > > > > > > > >>> were > >> > > > > > > > > > > > > > > > >>> > already working on a fix for that. I > >> > assume > >> > > > you > >> > > > > > are > >> > > > > > > > not > >> > > > > > > > > > and I > >> > > > > > > > > > > > > > would > >> > > > > > > > > > > > > > > > be > >> > > > > > > > > > > > > > > > >>> > sending a PR soon. > >> > > > > > > > > > > > > > > > >>> > > >> > > > > > > > > > > > > > > > >>> > On Tue, Nov 21, 2023 at 6:09 PM > Martin > >> > > Weiler > >> > > > > > > > > > > > > > > > <mwei...@ibm.com.invalid > >> > > > > > > > > > > > > > > > >>> > > >> > > > > > > > > > > > > > > > >>> > wrote: > >> > > > > > > > > > > > > > > > >>> > > >> > > > > > > > > > > > > > > > >>> > > I looked into the new examples > using > >> > > > > data-index > >> > > > > > > > > > persistence > >> > > > > > > > > > > > > > addon - > >> > > > > > > > > > > > > > > > >>> Neus' > >> > > > > > > > > > > > > > > > >>> > > PR#1813 [1] for serverless and > >> Pere's > >> > > > branch > >> > > > > > [2] > >> > > > > > > > for > >> > > > > > > > > > > > workflow > >> > > > > > > > > > > > > > > > (great > >> > > > > > > > > > > > > > > > >>> job > >> > > > > > > > > > > > > > > > >>> > > both!) - and they work without > >> issues > >> > > using > >> > > > > > > single > >> > > > > > > > > > > > requests. > >> > > > > > > > > > > > > > > > >>> However, under > >> > > > > > > > > > > > > > > > >>> > > some load (I used 'ab' for testing > >> > with a > >> > > > > light > >> > > > > > > > > > > > concurrency of > >> > > > > > > > > > > > > > 10 > >> > > > > > > > > > > > > > > > >>> parallel > >> > > > > > > > > > > > > > > > >>> > > requests) I ran into the following > >> > > > problems: > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > (1) Large number of insert/delete > >> calls > >> > > > (eg. > >> > > > > > for > >> > > > > > > > > tables > >> > > > > > > > > > > > such as > >> > > > > > > > > > > > > > > > >>> nodes, > >> > > > > > > > > > > > > > > > >>> > > definitions, etc) > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > (2) Hibernate > >> OptimisticLockExceptions > >> > / > >> > > > > > > > > > > > StaleStateExceptions > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > (3) DB deadlocks > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > (4) Error responses, slow response > >> > times > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > The reason I am reaching out with > >> this > >> > > > topic > >> > > > > > here > >> > > > > > > > is > >> > > > > > > > > to > >> > > > > > > > > > > > find > >> > > > > > > > > > > > > > out if > >> > > > > > > > > > > > > > > > >>> we are > >> > > > > > > > > > > > > > > > >>> > > aware of this issue, and if > someone > >> is > >> > > > > already > >> > > > > > > > > looking > >> > > > > > > > > > > > into or > >> > > > > > > > > > > > > > > > being > >> > > > > > > > > > > > > > > > >>> > > assigned to it? > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > Thanks, > >> > > > > > > > > > > > > > > > >>> > > Martin > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > [1] > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > >> > > > > > > > >> > https://github.com/apache/incubator-kie-kogito-examples/pull/1813 > >> > > > > > > > > > > > > > > > >>> > > [2] > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://github.com/pefernan/kogito-examples/tree/example_data-index_persistence > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > >> > > > > >> --------------------------------------------------------------------- > >> > > > > > > > > > > > > > > > >>> > > To unsubscribe, e-mail: > >> > > > > > > > > dev-unsubscr...@kie.apache.org > >> > > > > > > > > > > > > > > > >>> > > For additional commands, e-mail: > >> > > > > > > > > > dev-h...@kie.apache.org > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > >> > --------------------------------------------------------------------- > >> > > > > > > > > > > > > > > > >>> To unsubscribe, e-mail: > >> > > > > > > dev-unsubscr...@kie.apache.org > >> > > > > > > > > > > > > > > > >>> For additional commands, e-mail: > >> > > > > > > > dev-h...@kie.apache.org > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > > > > >>> > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > >> > > > > >> --------------------------------------------------------------------- > >> > > > > > > > > > > > > > > > > To unsubscribe, e-mail: > >> > > > > > dev-unsubscr...@kie.apache.org > >> > > > > > > > > > > > > > > > > For additional commands, e-mail: > >> > > > > > > dev-h...@kie.apache.org > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > >> > --------------------------------------------------------------------- > >> > > > > > > > > > > > > > To unsubscribe, e-mail: > >> > > dev-unsubscr...@kie.apache.org > >> > > > > > > > > > > > > > For additional commands, e-mail: > >> > > > dev-h...@kie.apache.org > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > >> > > > > >> --------------------------------------------------------------------- > >> > > > > > > > > > > > To unsubscribe, e-mail: > >> dev-unsubscr...@kie.apache.org > >> > > > > > > > > > > > For additional commands, e-mail: > >> > dev-h...@kie.apache.org > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > >> > --------------------------------------------------------------------- > >> > > > > > > > > > To unsubscribe, e-mail: > dev-unsubscr...@kie.apache.org > >> > > > > > > > > > For additional commands, e-mail: > >> dev-h...@kie.apache.org > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > >> --------------------------------------------------------------------- > >> > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > >> > > > > > > > > For additional commands, e-mail: > dev-h...@kie.apache.org > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > >> For additional commands, e-mail: dev-h...@kie.apache.org > >> > >> >
