redis sorted list performance issue when compression turned on

[chi qiu]

Hi,
I need to use the compression to save sorted set memory usage. But I
found sorted list performance dropped dramatically after compression
turned on. I plan to keep 3000 items in each list, so this is the
configuration I use:

zset-max-ziplist-entries 3000
zset-max-ziplist-value 3000

With compression turned off , I can get a 30000+ requests per second
performance and one CPU core usage for 40% (I am testing using a 10m
network). But if I turn on the compression , I can only get 3000
requests per second, and CPU core usage for 90%(I am testing on a
core2 2.65g CPU).
Looks like the cpu is the bottleneck of compression. Is there anything
I can do to improve performance with compression turned on ?
I noticed that Set's compression is using a IntSet instead, I can
encode all of my data to Integers, is that helpful to this Sorted Set
issue?

Thanks!

[chi qiu]

I've read the source code and find the performance issue may be caused by using ziplist, ziplist cannot archive O(N) speed(please correct me if I am wrong), so the performance dropped as the zset length grow. My question is is there anything I can do to reduce skiplist node object size in memory?
Thanks!

在 2012年6月15日星期五UTC+8下午1时24分31秒，chi qiu写道：

[Javier Guerra Giraldez]

On Fri, Jun 15, 2012 at 9:55 AM, chi qiu <qch...@gmail.com> wrote:
> My question is is there anything I can do to reduce skiplist node object
> size in memory?

compress it in the client?

--
Javier

[chi qiu]

Thanks, my data length is not long but I will give it a try.

在 2012年6月15日星期五UTC+8下午11时01分08秒，Javier Guerra写道：

[Josiah Carlson]

What the ziplist does is not compression, it is packing. Rather than
storing as structures, it stores it as packed data and has linear
access, as you mentioned.

When using ziplists, you are trading receiving reduced performance
along with reduced memory requirements. Your 3000 entries will be an
issue, and by just reducing the ziplist size to 300 entries, you would
likely see a jump in performance by 10x. Of course, you would also
likely see an increase in memory for any ZSET larger than 300 entries,
perhaps on the order of 10x over what you are experiencing now. I am
sorry to say, but there isn't any "free lunch" in this situation.
Either you get reduced space with reduced performance, or more space
with better performance.

If your strings are short, it is unlikely that compression will help.
And if you are using members that could be interpreted as integers
(like '38927'), those should already packed into a compact format (if
I remember correctly).

Regards,
- Josiah

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/redis-db/-/j9Flt0uU5DsJ.
>
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to
> redis-db+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=en.

[chi qiu]

Looks like compress will make things worse if I can map my String data to an Integer.

This is the result using gzip:
used_memory:171691736
used_memory_human:163.74M

This is the result using integer:
used_memory:118220672
used_memory_human:112.74M


在 2012年6月15日星期五UTC+8下午11时01分08秒，Javier Guerra写道：

[chi qiu]

Thanks. You are right, I just did a test, Integer will be better than compressing if possiable.
I think I have to give up. The integer magic is the best trick I can imagine.
在 2012年6月15日星期五UTC+8下午11时12分48秒，Josiah Carlson写道：

What the ziplist does is not compression, it is packing. Rather than
storing as structures, it stores it as packed data and has linear
access, as you mentioned.

When using ziplists, you are trading receiving reduced performance
along with reduced memory requirements. Your 3000 entries will be an
issue, and by just reducing the ziplist size to 300 entries, you would
likely see a jump in performance by 10x. Of course, you would also
likely see an increase in memory for any ZSET larger than 300 entries,
perhaps on the order of 10x over what you are experiencing now. I am
sorry to say, but there isn't any "free lunch" in this situation.
Either you get reduced space with reduced performance, or more space
with better performance.

If your strings are short, it is unlikely that compression will help.
And if you are using members that could be interpreted as integers
(like '38927'), those should already packed into a compact format (if
I remember correctly).

Regards,
 - Josiah

> redis-db+unsubscribe@googlegroups.com.

[Salvatore Sanfilippo]

What operation you run against the sorted set, when performance goes
from 30k+ to 3k+?

Thanks,
Salvatore

> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.

> To post to this group, send email to redi...@googlegroups.com.

> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
       — David Gelernter

[Javier Guerra Giraldez]

On Fri, Jun 15, 2012 at 10:30 AM, chi qiu <qch...@gmail.com> wrote:
> I think I have to give up. The integer magic is the best trick I can
> imagine.

if you can split your data in small zlists, say a few hundred of items
for each, then you could get the ziplist packing where linear
performance is still good.

of course this would be negated if you have to operate on all those
fragmentary lists every time. maybe you could set a small tree like?
some first check against a 'root' structure that tells you which small
list you have to use.

it all depends on what operations you need

--
Javier

[chi qiu]

I only run ZADD command to insert items, and ZremrangeByRank to keep the SET number less than 3000

在 2012年6月16日星期六UTC+8上午1时17分58秒，Salvatore Sanfilippo写道：

What operation you run against the sorted set, when performance goes
from 30k+ to 3k+?

Thanks,
Salvatore

On Fri, Jun 15, 2012 at 7:24 AM, chi qiu wrote:
> Hi,
> I need to use the compression to save sorted set memory usage. But I
> found sorted list performance dropped dramatically after compression
> turned on. I plan to keep 3000 items in each list, so this is the
> configuration I use:
>
> zset-max-ziplist-entries 3000
> zset-max-ziplist-value 3000
>
> With compression turned off , I can get a 30000+ requests per second
> performance and one CPU core usage for 40% (I am testing using a 10m
> network). But if I turn on the compression , I can only get 3000
> requests per second, and CPU core usage for 90%(I am testing on a
> core2 2.65g CPU).
> Looks like the cpu is the bottleneck of compression. Is there anything
> I can do to improve performance with compression turned on ?
> I noticed that Set's compression is using a IntSet instead, I can
> encode all of my data to Integers, is that helpful to this Sorted Set
> issue?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.

> To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.

[chi qiu]

I am using sorted list as a priority queue. I will test if I can sync a segmented queue between redis and my application.
Thanks.
Charlie.
在 2012年6月16日星期六UTC+8上午1时53分23秒，Javier Guerra写道：

[Josiah Carlson]

How many queues do you have? How big are your items?

- Josiah

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/redis-db/-/dnrwa3YYwScJ.

>
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to

> redis-db+u...@googlegroups.com.

[chi qiu]

Queue number is very large, there are tens of thousands queues. Items are very small, usually less than 20 bytes.
Thanks
Charlie
在 2012年6月16日星期六UTC+8下午1时46分08秒，Josiah Carlson写道：

How many queues do you have? How big are your items?

 - Josiah

> redis-db+unsubscribe@googlegroups.com.