You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-dev@jakarta.apache.org by Aaron Smuts <as...@yahoo.com> on 2004/07/19 18:40:09 UTC
JCS vs. Hashtable
The JSR 107 set a tentative performance goal for a
cache at <2x a Hastable.
JCS, using the LRUMemoryCache, is exceeding this
performance goal. Here are aome results from a few
simple tests:
------------------------------------------
Finished 20 loops of 50000 gets and puts
Put average for JCS = 235
Put average for Hashtable = 157
JCS puts took 1.4968153 times the Hashtable, the goal
is <2x
Get average for JCS = 132
Get average for Hashtable = 99
JCS gets took 1.3333334 times the Hashtable, the goal
is <2x
------------------------------------------
Finished 20 loops of 50000 gets and puts
Put average for JCS = 247
Put average for Hashtable = 167
JCS puts took 1.4790419 times the Hashtable, the goal
is <2x
Get average for JCS = 131
Get average for Hashtable = 100
JCS gets took 1.31 times the Hashtable, the goal is
<2x
------------------------------------------
Finished 20 loops of 50000 gets and puts
Put average for JCS = 242
Put average for Hashtable = 170
JCS puts took 1.4235294 times the Hashtable, the goal
is <2x
Get average for JCS = 138
Get average for Hashtable = 102
JCS gets took 1.3529412 times the Hashtable, the goal
is <2x
------------------------------------------
Finished 20 loops of 50000 gets and puts
Put average for JCS = 242
Put average for Hashtable = 164
JCS puts took 1.4756098 times the Hashtable, the goal
is <2x
Get average for JCS = 135
Get average for Hashtable = 100
JCS gets took 1.35 times the Hashtable, the goal is
<2x
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: groups
Posted by Aaron Smuts <as...@yahoo.com>.
2 stage group conversion:
1. Use the element attributes to store the group
name.
Convert all getgroup funtions to look in the
element attributes.
2. If needed implement a group id map for lookups.
Do all the work in composite cache. Store the groupid
map in the same region as the elements. Give it some
special property so it will not fall off the lru or
write the code such that if it falls off, we can
revert to the iteration through the kesy method and
rebuild the map. This may be best.
Aaron
--- Aaron Smuts <as...@yahoo.com> wrote:
> The JCS hierarchical remove is more powerful than
> groups. JCS grouping needs an overhaul.
>
> The old JCS grouping was designed for fast removal
> and
> gets, faster than hierarchical removal. We stored
> the
> keys for groups in a hashtable in the systemgroupid
> region. This allowed for quick lookups of group
> keys
> and fast removal. To get the keys for a group, the
> map for the group ids was retrieved and all the
> values
> were spit out. This didn't require locking the
> entire
> map for a region to retrieve group keys.
>
> There were some synchronization problems in the old
> group implementation, so it was changed. Currently,
> the systemgroupid region is not used. Groups are
> referenced by a special key. When you want a list
> of
> the keys in a group, the cache iterates through all
> the keys in a region. The current implementation
> does
> not allow grouped items to be retrieved by their key
> alone. As a result, groups function as mini regions
> with slow removal times. It would be better to use
> another region than the current groups.
> Alternatively, the hierarchical removal can do most
> of
> what you need.
>
> Ideally, none of the auxiliaries needs to know about
> groups. The CompositeCache should be able to manage
> it all.
>
>
> The group functionality needs to be changed.
>
> Items in a group within a region should be able to
> be
> referenced by the key alone. We can make this
> happen
> by putting an object, CacheKey, in the CacheElement
> and have it equal an object with a similar key in a
> GroupAttrName, but this adds some complexity.
>
> One alternative is to completely remove groups until
> we work out a way to bring back the group key map.
>
> Another option, if we only want to support single
> groups, is to add a groupname or a list of group
> names
> to the ElementAttributes. We could continue to
> iterate through the map for group reference. We
> could
> allow for multiple groups this way, but it would
> have
> the same slowness problems. It would allow grouped
> items to be retrieved by their common keys. All in
> all, I think this is the best alternative for now.
>
> Let's scrap the GroupAttrName and just put the group
> information in the ElementAttributes until, or if,
> we
> decide to use the group key maps again. This does
> still require the auxiliaries to be able to handle
> getGroupKeys requests.
>
>
> Aaron
>
>
>
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
>
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: groups
Posted by Aaron Smuts <as...@yahoo.com>.
2 stage group conversion:
1. Use the element attributes to store the group
name.
--- Aaron Smuts <as...@yahoo.com> wrote:
> The JCS hierarchical remove is more powerful than
> groups. JCS grouping needs an overhaul.
>
> The old JCS grouping was designed for fast removal
> and
> gets, faster than hierarchical removal. We stored
> the
> keys for groups in a hashtable in the systemgroupid
> region. This allowed for quick lookups of group
> keys
> and fast removal. To get the keys for a group, the
> map for the group ids was retrieved and all the
> values
> were spit out. This didn't require locking the
> entire
> map for a region to retrieve group keys.
>
> There were some synchronization problems in the old
> group implementation, so it was changed. Currently,
> the systemgroupid region is not used. Groups are
> referenced by a special key. When you want a list
> of
> the keys in a group, the cache iterates through all
> the keys in a region. The current implementation
> does
> not allow grouped items to be retrieved by their key
> alone. As a result, groups function as mini regions
> with slow removal times. It would be better to use
> another region than the current groups.
> Alternatively, the hierarchical removal can do most
> of
> what you need.
>
> Ideally, none of the auxiliaries needs to know about
> groups. The CompositeCache should be able to manage
> it all.
>
>
> The group functionality needs to be changed.
>
> Items in a group within a region should be able to
> be
> referenced by the key alone. We can make this
> happen
> by putting an object, CacheKey, in the CacheElement
> and have it equal an object with a similar key in a
> GroupAttrName, but this adds some complexity.
>
> One alternative is to completely remove groups until
> we work out a way to bring back the group key map.
>
> Another option, if we only want to support single
> groups, is to add a groupname or a list of group
> names
> to the ElementAttributes. We could continue to
> iterate through the map for group reference. We
> could
> allow for multiple groups this way, but it would
> have
> the same slowness problems. It would allow grouped
> items to be retrieved by their common keys. All in
> all, I think this is the best alternative for now.
>
> Let's scrap the GroupAttrName and just put the group
> information in the ElementAttributes until, or if,
> we
> decide to use the group key maps again. This does
> still require the auxiliaries to be able to handle
> getGroupKeys requests.
>
>
> Aaron
>
>
>
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
>
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
groups
Posted by Aaron Smuts <as...@yahoo.com>.
The JCS hierarchical remove is more powerful than
groups. JCS grouping needs an overhaul.
The old JCS grouping was designed for fast removal and
gets, faster than hierarchical removal. We stored the
keys for groups in a hashtable in the systemgroupid
region. This allowed for quick lookups of group keys
and fast removal. To get the keys for a group, the
map for the group ids was retrieved and all the values
were spit out. This didn't require locking the entire
map for a region to retrieve group keys.
There were some synchronization problems in the old
group implementation, so it was changed. Currently,
the systemgroupid region is not used. Groups are
referenced by a special key. When you want a list of
the keys in a group, the cache iterates through all
the keys in a region. The current implementation does
not allow grouped items to be retrieved by their key
alone. As a result, groups function as mini regions
with slow removal times. It would be better to use
another region than the current groups.
Alternatively, the hierarchical removal can do most of
what you need.
Ideally, none of the auxiliaries needs to know about
groups. The CompositeCache should be able to manage
it all.
The group functionality needs to be changed.
Items in a group within a region should be able to be
referenced by the key alone. We can make this happen
by putting an object, CacheKey, in the CacheElement
and have it equal an object with a similar key in a
GroupAttrName, but this adds some complexity.
One alternative is to completely remove groups until
we work out a way to bring back the group key map.
Another option, if we only want to support single
groups, is to add a groupname or a list of group names
to the ElementAttributes. We could continue to
iterate through the map for group reference. We could
allow for multiple groups this way, but it would have
the same slowness problems. It would allow grouped
items to be retrieved by their common keys. All in
all, I think this is the best alternative for now.
Let's scrap the GroupAttrName and just put the group
information in the ElementAttributes until, or if, we
decide to use the group key maps again. This does
still require the auxiliaries to be able to handle
getGroupKeys requests.
Aaron
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
Re: JCS vs. Hashtable
Posted by Aaron Smuts <as...@yahoo.com>.
Exceeding a goal is ambiguous. JCS is meeting the
performance goal and then some. Times for a region
using the LRUMemoryCache are near Hashtable for get
and sometimes better for puts.
I'm adding a unit test that enforces this minimum
standard on the LRUMemoryCache.
Outside the IDE, through junit tests in the Maven
build, I'm consistently getting better results for
puts in JCS than in the Hashtable.
ex.
Finished 20 loops of 50000 gets and puts
Put average for JCS = 312
Put average for Hashtable = 349
JCS puts took 0.8939828 times the Hashtable, the goal
is <2.5x
Get average for JCS = 91
Get average for Hashtable = 56
JCS gets took 1.625 times the Hashtable, the goal is
<2.5x
Aaron
--- Aaron Smuts <as...@yahoo.com> wrote:
> The JSR 107 set a tentative performance goal for a
> cache at <2x a Hastable.
>
> JCS, using the LRUMemoryCache, is exceeding this
> performance goal. Here are aome results from a few
> simple tests:
>
> ------------------------------------------
> Finished 20 loops of 50000 gets and puts
>
> Put average for JCS = 235
> Put average for Hashtable = 157
> JCS puts took 1.4968153 times the Hashtable, the
> goal
> is <2x
>
> Get average for JCS = 132
> Get average for Hashtable = 99
> JCS gets took 1.3333334 times the Hashtable, the
> goal
> is <2x
>
>
> ------------------------------------------
> Finished 20 loops of 50000 gets and puts
>
> Put average for JCS = 247
> Put average for Hashtable = 167
> JCS puts took 1.4790419 times the Hashtable, the
> goal
> is <2x
>
> Get average for JCS = 131
> Get average for Hashtable = 100
> JCS gets took 1.31 times the Hashtable, the goal is
> <2x
>
>
> ------------------------------------------
> Finished 20 loops of 50000 gets and puts
>
> Put average for JCS = 242
> Put average for Hashtable = 170
> JCS puts took 1.4235294 times the Hashtable, the
> goal
> is <2x
>
> Get average for JCS = 138
> Get average for Hashtable = 102
> JCS gets took 1.3529412 times the Hashtable, the
> goal
> is <2x
>
> ------------------------------------------
> Finished 20 loops of 50000 gets and puts
>
> Put average for JCS = 242
> Put average for Hashtable = 164
> JCS puts took 1.4756098 times the Hashtable, the
> goal
> is <2x
>
> Get average for JCS = 135
> Get average for Hashtable = 100
> JCS gets took 1.35 times the Hashtable, the goal is
> <2x
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org