[
https://issues.apache.org/jira/browse/UNOMI-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Jahanshahi updated UNOMI-741:
-----------------------------------
Description:
-Following performance tests done on ticket:
https://issues.apache.org/jira/browse/UNOMI-725-
-We need to implement sessionId/indexName affinity cache to speed up access to
current user session on context requests.-
-Due to the nature of the splitted indices for the sessions it's not possible
to know where exactly is stored the sessionId from the context request.-
-We can do a query like it is right now but as shown in the performances
results test this is impact a lot the performance for concurrent context
requests.-
-So we need to implement a sessionId/indexName affinity cache in the
persistence service to speed up the loading of current user sessions.-
-consider a cache system with a time-to-idle feature that will automatically
clean the unused sessionId after 30min and make this configurable.-
-PoC PR:- [-https://github.com/apache/unomi/pull/576-]
h2. New Decision:
We will use a new strategy to retrieve session:
* try to retrieve session in the last known session index
* Store the last know session index in memory, update it if necessary if
session save request return a new session index (means a rollover happened)
* revert merged PR: https://github.com/apache/unomi/pull/576
Disclaimer: We are aware of the fact that sessions may be reset in case they
are still alive while a rollover happen.
was:
-Following performance tests done on ticket:
https://issues.apache.org/jira/browse/UNOMI-725-
-We need to implement sessionId/indexName affinity cache to speed up access to
current user session on context requests.-
-Due to the nature of the splitted indices for the sessions it's not possible
to know where exactly is stored the sessionId from the context request.-
-We can do a query like it is right now but as shown in the performances
results test this is impact a lot the performance for concurrent context
requests.-
-So we need to implement a sessionId/indexName affinity cache in the
persistence service to speed up the loading of current user sessions.-
-consider a cache system with a time-to-idle feature that will automatically
clean the unused sessionId after 30min and make this configurable.-
-PoC PR:- [-https://github.com/apache/unomi/pull/576-]
h2. New Decision:
We will use a new strategy to retrieve session:
* try to retrieve session in the last known session index
* Store the last know session index in memory, update it if necessary if
session save request return a new session index (means a rollover happened)
Disclaimer: We are aware of the fact that sessions may be reset in case they
are still alive while a rollover happen.
> Session/Event index rollover: Session retrieval strategy
> --------------------------------------------------------
>
> Key: UNOMI-741
> URL: https://issues.apache.org/jira/browse/UNOMI-741
> Project: Apache Unomi
> Issue Type: Task
> Reporter: Kevan Jahanshahi
> Priority: Major
> Fix For: unomi-2.2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> -Following performance tests done on ticket:
> https://issues.apache.org/jira/browse/UNOMI-725-
> -We need to implement sessionId/indexName affinity cache to speed up access
> to current user session on context requests.-
> -Due to the nature of the splitted indices for the sessions it's not possible
> to know where exactly is stored the sessionId from the context request.-
> -We can do a query like it is right now but as shown in the performances
> results test this is impact a lot the performance for concurrent context
> requests.-
> -So we need to implement a sessionId/indexName affinity cache in the
> persistence service to speed up the loading of current user sessions.-
> -consider a cache system with a time-to-idle feature that will automatically
> clean the unused sessionId after 30min and make this configurable.-
> -PoC PR:- [-https://github.com/apache/unomi/pull/576-]
> h2. New Decision:
> We will use a new strategy to retrieve session:
> * try to retrieve session in the last known session index
> * Store the last know session index in memory, update it if necessary if
> session save request return a new session index (means a rollover happened)
> * revert merged PR: https://github.com/apache/unomi/pull/576
> Disclaimer: We are aware of the fact that sessions may be reset in case they
> are still alive while a rollover happen.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
