Changes for page Notifications Optimization
Last modified by Vincent Massol on 2024/02/26 17:53
To version 9.1
edited by Vincent Massol
on 2019/03/06 15:28
on 2019/03/06 15:28
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Objects (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -102,6 +102,7 @@ 102 102 * "Event Status" are generated for users who never goes to the wikis, which is a waste of resource. 103 103 * The "Event Status" table should probably be cleaned regularly to avoid having too much data, meaning some precious notifications could be lost while a user is absent (like a 2 weeks holidays). 104 104 * **This mechanism cannot be applied for the Notifications Macro (that was designed to replace the Activity Stream), so it means both mechanism should co-exists.** 105 +* A thread pool is required anyway, see Solution 1B. 105 105 ))) 106 106 ))) 107 107 ))) ... ... @@ -110,6 +110,7 @@ 110 110 111 111 * Which store should be used to sore the "Event Status" table? Currently, it is a table in hibernate, but SOLR could be considered, or any NoSQL solution. 112 112 * Does it scale? 114 +** How long does it take to perform 200K writes (this is what would happen for a wiki with 200K users when everyone is subscribed to the right events and a page is modified for ex)? 113 113 114 114 = Temporary conclusion = 115 115
- ProposalCode.ProposalClass[0]
-
- Participants
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.gdelhumeau,xwiki:XWiki.ThomasMortagne,xwiki:XWiki.VincentMassol