[KULRICE-4421] SessionDocumentService can be a performance bottleneck Created: 03/Aug/10  Updated: 21/May/15  Resolved: 13/Mar/13

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: 1.0.2.1
Fix Version/s: Not version specific

Type: Bug Fix Priority: Critical
Reporter: Jonathan Keller Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates KFSMI-5916 SessionDocumentService can be a perfo... Rice Roadblock
duplicates KULRICE-9148 Disable SessionDocumentService in the... Closed
duplicates KULRICE-9149 Remove usage of org.kuali.rice.krad.s... Closed
Similar issues:
KULRICE-7009Profile the view process (complete request/response) for bottlenecks
KULRICE-9424Profile script execution to identify top bottlenecks
KULRICE-8962CloneUtils deepCloneObject Performance Improvement
KULRICE-14090Make improvements to KIM integration performance
KULRICE-9148Disable SessionDocumentService in the KNS
KULRICE-9230KNS should not use the KRAD SessionDocumentService
KULRICE-8946A few small things that can improve KRAD performance
KULRICE-10178Remove SessionDocumentService from KRAD
KULRICE-9358Form and WorkflowDocument no longer being persisted to session after disabling the SessionDocumentService
KULRICE-9895Install Jenkins Performance Plugin
Rice Module:
KNS
Application Requirement:
KFS, KC, Rice

 Description   

It appears that the SessionDocumentService is a major source of performance issues, especially for large documents. For every request the user makes on the document, the entire document is serialized and transferred to and from the database.

Some of the performance may be due to the size of the connection pool, but across two servers it should have been sufficient for the number of users who were testing. It really seemed to have to do with the sheer amount of data being transferred. On some maintenance documents (which is all we were testing), the serialized object graph was over a megabyte.

By stubbing out the service to remove the feature altogether, we were able to greatly improve server performance. That may not be the ultimate solution, but it meets UCDs needs at the moment.

Another option would be to use a shared file system for such a store, since that would be faster to access than via the database connections.



 Comments   
Comment by Eric Westfall [ 13/Mar/13 ]

Closing this issue as a duplicate of KULRICE-9148 and KULRICE-9149

Generated at Wed Oct 23 01:05:12 CDT 2019 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.