近期接到一个需求,因并发访问单张表导致时延过大,需要拆成10张表,对于ObjID模10来访问对应的表。
因涉及并发及statement缓存,将原单个字符串sql语句扩展为长度为10的字符串数组,将单个statement缓存扩展为长度为10的statement缓存数组。
增加开关判断,true时走分表逻辑,false时走原逻辑。
原始代码为
修改为
性能下降严重,各种分析、求助无果。
总是有一种感觉,是mod带来的性能下降,于是改为与运算。
重新测试,性能和开关关闭时持平,达到预期效果。
从指令数分析,取模运算和与运算也仅差一个指令,这点差异对应几百万指令简直是九牛一毛,
但是效果却有如此大的差异,至于具体原因,苦思无果,难道触发了蝴蝶效应。。。
领导们和SE们都很怀疑,看到结果也只能事实胜于雄辩了。
因涉及并发及statement缓存,将原单个字符串sql语句扩展为长度为10的字符串数组,将单个statement缓存扩展为长度为10的statement缓存数组。
增加开关判断,true时走分表逻辑,false时走原逻辑。
原始代码为
int funcName(long objID,...)
{
int iRet = getPreparedStatement(m_objStmt, CONST_SQL);
......
}
修改为
int funcName(long objID,...)
{
STMT * stmtTmp;
const char* pSqlStr;
if (isSplitTable())
{
long step = objID % 10;
pSqlStr = CONST_SQLSTR_LIST_FOR_SPLIT[step];
stmtTmp = &(m_objStmtList[step]);
}
else
{
stmtTmp = &(m_objStmtList[0]);
pSqlStr = CONST_SQLSTR;
}
int iRet = getPreparedStatement(*stmtTmp, pSqlStr);
......
}
开关关闭时性能和修改前持平,打开时下降明显。
性能下降严重,各种分析、求助无果。
总是有一种感觉,是mod带来的性能下降,于是改为与运算。
重新测试,性能和开关关闭时持平,达到预期效果。
从指令数分析,取模运算和与运算也仅差一个指令,这点差异对应几百万指令简直是九牛一毛,
但是效果却有如此大的差异,至于具体原因,苦思无果,难道触发了蝴蝶效应。。。
领导们和SE们都很怀疑,看到结果也只能事实胜于雄辩了。
const long SPILIT_AND_OPERATION_BASE_NUM = 7;
int funcName(long objID,...)
{
STMT * stmtTmp;
const char* pSqlStr;
if (isSplitTable())
{
long step = objID & SPILIT_AND_OPERATION_BASE_NUM;
pSqlStr = CONST_SQLSTR_LIST_FOR_SPLIT[step];
stmtTmp = &(m_objStmtList[step]);
}
else
{
stmtTmp = &(m_objStmtList[0]);
pSqlStr = CONST_SQLSTR;
}
int iRet = getPreparedStatement(*stmtTmp, pSqlStr);
......
}
或许可以作为性能优化点,对于2的n次方的取模运算,可以改为2的n次方-1的与运算。