* @since 12-2-9 下午3:31
*
*/
int index = Integer.valueOf(args[0])
AtomicLong id = new AtomicLong((index - 1) * step + 1)
TDHSClient client = new TDHSClientImpl(new InetSocketAddress("10.232.31.25", 9999), 2);
def s = new StressTest(count: step)
s.add({
def _id = id.incrementAndGet()
String table = "test"
TDHSResponse response = client.createStatement(index).insert().use("benchmark_insert").from(table)
.value("id", _id.toString())
.value("k", "10000")
.value("i", _id.toString())
.value("c", _id.toString() + "_abcdefghijklmnopqrstuvwxyz").insert()
if (response != null && response.getStatus() != TDHSResponseEnum.ClientStatus.OK) {
}
}, 100)
s.run()
client.shutdown()
使用TDH_SOCKET進行插入能到這么高TPS的關鍵:
TDH_SOCKET提供group commit:
減少redo log的fsync次數,使IOPS不成為瓶頸
TDH_SOCKET能提供并發寫.
自增id的生成策略需要分段自增:
如果采用全自增id生成策略(即默認innodb提供的自增id生成策略)的話,會在高并發插入的時候遇到一個block的寫鎖.
因為是順序自增,所以并發插入的記錄都會集中寫入到同一個page上,而一個線程寫page會對這個page做一次 rw_lock_x_lock_func(&(block->lock), 0, file, line); 那么這個寫鎖會成為瓶頸,使TPS無法上去所以只要改變生成id的策略:
分段自增比如一個寫線程一下子獲取1-10000的id范圍 下一個寫線程獲取10001-20000的id范圍..
每個寫線程在各自的范圍里面自增的生成id,那么即能保證一定的順序寫,又能使寫page不會因為并發寫鎖而性能下降!
至于TDH_SOCKET是啥…..先買個關子~
原文轉自:http://blogread.cn/it/article/5070