History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CACHE-197
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Andres March
Reporter: Christoph Kutzinski
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
OSCache

Speed up disk persistence

Created: 26/Sep/05 05:56 AM   Updated: 22/Jan/06 08:51 PM
Component/s: Listeners
Affects Version/s: 2.1.1, 2.2 RC
Fix Version/s: 2.3

File Attachments: 1. Java Source File AbstractDiskPersistenceListener.java (18 kb)
2. File AbstractDiskPersistenceListener.java.patch_2.2-rc (19 kb)



 Description  « Hide
The DiskPersistenceListener can be sped up in various ways.
Reasoning: when one is "hard" removing a bigger number of cache entries with groups assigned (see http://jira.opensymphony.com/browse/CACHE-188?page=comments#action_26810), the operation will be incredible slow. This is obviously due to the fact that for each entry 1+x files have to be touched (x is the number of groups the entry is in).

 All   Comments   Change History      Sort Order:
Christoph Kutzinski - [26/Sep/05 06:52 AM ]
This is the patched AbstractDiskPersistenceListener based on OSCache 2.1.1

There are 3 main changes:
- don't delete cache files before storing (not necessary IMHO since the file will be overwritten by the outputstream anyway)
- used buffered in and output streams
This gave me a performance gain of ca. 20% for removing 750 entries with each around 3 groups

- don't serialize groups, but write them as plain strings
This gave me another 20%

Caveat: the last change isn't compatible with group files written by old versions.

Lars Torunski - [26/Sep/05 05:10 PM ]
I merged your changes in the 2.1.1 release file with the bug fix CACHE-189 of the 2.2 rc release.
Please check if the merges are correct in AbstractDiskPersistenceListener.java.patch_2.2-rc file.

Christoph Kutzinski - [27/Sep/05 02:46 AM ]
The patch looks good to me.

(I wanted to report one minor issue, since I thought that the fout.close() call in store() is redundant. But I just realised that the ObjectInputStream constructor can throw an exception, so it isn't)

Lars Torunski - [12/Nov/05 03:38 AM ]
Using buffered in and output streams to increase persisting performance about 20%.
Groups are still serialized for backward reasons.