cjson的encode,decode很耗时，该怎么解决

wangwei4514 · 2016-04-07T17:18:18+00:00

Hello! 2016-03-28 7:12 GMT-07:00 付海清: > 情况是这样的： > > 我们用&...

cjson的encode,decode很耗时，该怎么解决

wangwei4514

问题：

后台有很多机器，每个请求过来后，会根据request header中的host来选择对应的后端（通过balancer_by_lua_file实现）

host与后端的队列关系如下：站点大概有10W个

{

'website1.com':

{

'host': '127.0.0.1',

'port': 8000

{

'host': '127.0.0.2',

'port': 8001

...

}

{

'website2.com':

{

'host': '127.0.0.3',

'port': 8011

{

'host': '127.0.0.4',

'port': 8012

...

}

...

我现在的处理方案是采用ngx.shared.dict存host与后端的对应关系，由于shared.dict的value不能为table，所以将后端机器先用json.encode，等处理的时候再用json.decode解码，今天压测时发现1.7W QPS时cpu利用率就有60%，通过火焰图发现json的encode，decode占了很长的时间。

dict = {

'website1.com': 'xxxxx',

'website2.com': 'xxxxx'

...

}

请问，json占cpu高有啥优化方案吗？或是不采用shared.dict，有别的替代方案没？

uangxi

试试 lua-resty-lrucache

On Thursday, April 7, 2016 at 5:18:18 PM UTC+8, wangw...@gmail.com wrote:

问题：
后台有很多机器，每个请求过来后，会根据request header中的host来选择对应的后端（通过balancer_by_lua_file实现）
host与后端的队列关系如下：站点大概有10W个
{
'website1.com':
{
{
'host': '127.0.0.1',
'port': 8000
},
{
'host': '127.0.0.2',
'port': 8001
},
...
}
}
{
'website2.com':
{
{
'host': '127.0.0.3',
'port': 8011
},
{
'host': '127.0.0.4',
'port': 8012
},
...
}
}
...

我现在的处理方案是采用ngx.shared.dict存host与后端的对应关系，由于shared.dict的value不能为table，所以将后端机器先用json.encode，等处理的时候再用json.decode解码，今天压测时发现1.7W QPS时cpu利用率就有60%，通过火焰图发现json的encode，decode占了很长的时间。
dict = {
'website1.com': 'xxxxx',
'website2.com': 'xxxxx'
...
}

请问，json占cpu高有啥优化方案吗？或是不采用shared.dict，有别的替代方案没？

yinjun322

直接把 “website1.com” 定义成 key 不行吗？

在 2016年4月7日星期四 UTC+8下午5:18:18，wangw...@gmail.com写道：

问题：
后台有很多机器，每个请求过来后，会根据request header中的host来选择对应的后端（通过balancer_by_lua_file实现）
host与后端的队列关系如下：站点大概有10W个
{
'website1.com':
{
{
'host': '127.0.0.1',
'port': 8000
},
{
'host': '127.0.0.2',
'port': 8001
},
...
}
}
{
'website2.com':
{
{
'host': '127.0.0.3',
'port': 8011
},
{
'host': '127.0.0.4',
'port': 8012
},
...
}
}
...

我现在的处理方案是采用ngx.shared.dict存host与后端的对应关系，由于shared.dict的value不能为table，所以将后端机器先用json.encode，等处理的时候再用json.decode解码，今天压测时发现1.7W QPS时cpu利用率就有60%，通过火焰图发现json的encode，decode占了很长的时间。
dict = {
'website1.com': 'xxxxx',
'website2.com': 'xxxxx'
...
}

请问，json占cpu高有啥优化方案吗？或是不采用shared.dict，有别的替代方案没？

guanglinlv

在做性能优化时，我有遇到和你一样的问题。@XI WANG回答的是直接，使用lua-resty-lrucache对解码后的lua表做缓存；

需要注意的是，lua-resty-lrucache的缓存单worker内共享的，所以更不存在并非读写的问题。你可以使用lua module的机制来为每个worker初始化一个lrucache实例；

https://github.com/openresty/lua-resty-lrucache

在 2016年4月7日星期四 UTC+8下午5:18:18，wangw...@gmail.com写道：

问题：
后台有很多机器，每个请求过来后，会根据request header中的host来选择对应的后端（通过balancer_by_lua_file实现）
host与后端的队列关系如下：站点大概有10W个
{
'website1.com':
{
{
'host': '127.0.0.1',
'port': 8000
},
{
'host': '127.0.0.2',
'port': 8001
},
...
}
}
{
'website2.com':
{
{
'host': '127.0.0.3',
'port': 8011
},
{
'host': '127.0.0.4',
'port': 8012
},
...
}
}
...

我现在的处理方案是采用ngx.shared.dict存host与后端的对应关系，由于shared.dict的value不能为table，所以将后端机器先用json.encode，等处理的时候再用json.decode解码，今天压测时发现1.7W QPS时cpu利用率就有60%，通过火焰图发现json的encode，decode占了很长的时间。
dict = {
'website1.com': 'xxxxx',
'website2.com': 'xxxxx'
...
}

请问，json占cpu高有啥优化方案吗？或是不采用shared.dict，有别的替代方案没？

wangwei4514

“website1.com”这个是定义成key的，主要是对value进行的编码，解码

在 2016年4月8日星期五 UTC+8上午10:06:49，老鬼来了写道：

直接把 “website1.com” 定义成 key 不行吗？

在 2016年4月7日星期四 UTC+8下午5:18:18，wangw...@gmail.com写道：
问题：
后台有很多机器，每个请求过来后，会根据request header中的host来选择对应的后端（通过balancer_by_lua_file实现）
host与后端的队列关系如下：站点大概有10W个
{
'website1.com':
{
{
'host': '127.0.0.1',
'port': 8000
},
{
'host': '127.0.0.2',
'port': 8001
},
...
}
}
{
'website2.com':
{
{
'host': '127.0.0.3',
'port': 8011
},
{
'host': '127.0.0.4',
'port': 8012
},
...
}
}
...

我现在的处理方案是采用ngx.shared.dict存host与后端的对应关系，由于shared.dict的value不能为table，所以将后端机器先用json.encode，等处理的时候再用json.decode解码，今天压测时发现1.7W QPS时cpu利用率就有60%，通过火焰图发现json的encode，decode占了很长的时间。
dict = {
'website1.com': 'xxxxx',
'website2.com': 'xxxxx'
...
}

请问，json占cpu高有啥优化方案吗？或是不采用shared.dict，有别的替代方案没？

wangwei4514

多谢解惑，我把@XI WANG的理解为用lrucache来代替shared.dict了，原来是用lrucache来缓存解码后的lua表

在 2016年4月8日星期五 UTC+8上午10:59:20，Guanglin Lv写道：

在做性能优化时，我有遇到和你一样的问题。@XI WANG回答的是直接，使用lua-resty-lrucache对解码后的lua表做缓存；

需要注意的是，lua-resty-lrucache的缓存单worker内共享的，所以更不存在并非读写的问题。你可以使用lua module的机制来为每个worker初始化一个lrucache实例；

https://github.com/openresty/lua-resty-lrucache

在 2016年4月7日星期四 UTC+8下午5:18:18，wangw...@gmail.com写道：
问题：
后台有很多机器，每个请求过来后，会根据request header中的host来选择对应的后端（通过balancer_by_lua_file实现）
host与后端的队列关系如下：站点大概有10W个
{
'website1.com':
{
{
'host': '127.0.0.1',
'port': 8000
},
{
'host': '127.0.0.2',
'port': 8001
},
...
}
}
{
'website2.com':
{
{
'host': '127.0.0.3',
'port': 8011
},
{
'host': '127.0.0.4',
'port': 8012
},
...
}
}
...

我现在的处理方案是采用ngx.shared.dict存host与后端的对应关系，由于shared.dict的value不能为table，所以将后端机器先用json.encode，等处理的时候再用json.decode解码，今天压测时发现1.7W QPS时cpu利用率就有60%，通过火焰图发现json的encode，decode占了很长的时间。
dict = {
'website1.com': 'xxxxx',
'website2.com': 'xxxxx'
...
}

请问，json占cpu高有啥优化方案吗？或是不采用shared.dict，有别的替代方案没？

guanglinlv

上次手机打的，有很多错别字哈，见谅啦；

可以理解为是替代shared dict的，如果你的场景并不需要跨worker共享；不然shared dict也存一份序列化的东西也没啥用处；

在 2016年4月8日星期五 UTC+8下午7:34:24，wangw...@gmail.com写道：

多谢解惑，我把@XI WANG的理解为用lrucache来代替shared.dict了，原来是用lrucache来缓存解码后的lua表

在 2016年4月8日星期五 UTC+8上午10:59:20，Guanglin Lv写道：

在做性能优化时，我有遇到和你一样的问题。@XI WANG回答的是直接，使用lua-resty-lrucache对解码后的lua表做缓存；

需要注意的是，lua-resty-lrucache的缓存单worker内共享的，所以更不存在并非读写的问题。你可以使用lua module的机制来为每个worker初始化一个lrucache实例；

https://github.com/openresty/lua-resty-lrucache

在 2016年4月7日星期四 UTC+8下午5:18:18，wangw...@gmail.com写道：
问题：
后台有很多机器，每个请求过来后，会根据request header中的host来选择对应的后端（通过balancer_by_lua_file实现）
host与后端的队列关系如下：站点大概有10W个
{
'website1.com':
{
{
'host': '127.0.0.1',
'port': 8000
},
{
'host': '127.0.0.2',
'port': 8001
},
...
}
}
{
'website2.com':
{
{
'host': '127.0.0.3',
'port': 8011
},
{
'host': '127.0.0.4',
'port': 8012
},
...
}
}
...

我现在的处理方案是采用ngx.shared.dict存host与后端的对应关系，由于shared.dict的value不能为table，所以将后端机器先用json.encode，等处理的时候再用json.decode解码，今天压测时发现1.7W QPS时cpu利用率就有60%，通过火焰图发现json的encode，decode占了很长的时间。
dict = {
'website1.com': 'xxxxx',
'website2.com': 'xxxxx'
...
}

请问，json占cpu高有啥优化方案吗？或是不采用shared.dict，有别的替代方案没？