SPHINX单台服务器利用多核性能测试

 在网上上看到一篇文章，用到sphinx的分布式特性来提高搜索性能，就做了个简单的测试。

1. sphinx配置.

配置加粗部分是核心，让sphinx支持分布式。

source multi1
{
    type            = mysql
    sql_host        = 127.0.0.1
    sql_user        = root
    sql_pass        = passwd
    sql_db        = cs
    sql_port        = 3306    
    sql_query        = select id,title,content from fts_index where id%2=0    
    sql_ranged_throttle    = 0
}
source multi2{
    type            = mysql
    sql_host        = 127.0.0.1
    sql_user        = root
    sql_pass        = passwd
    sql_db        = cs
    sql_port        = 3306    
    sql_query        = select id,title,content from fts_index where id%2=1    
    sql_ranged_throttle    = 0
}
index multi1{
    source = multi1    path = /usr/local/coreseek/var/data/multi1}
 
index multi2{
    source = multi2    path = /usr/local/coreseek/var/data/multi2}

index search
{
    type = distributed
    local = multi1    local = multi2
}

 

没有分布式的配置，这个么什么好说的

source main
{
    type            = mysql
    sql_host        = 127.0.0.1
    sql_user        = root
    sql_pass        = passwd
    sql_db      = cs
    sql_port        = 3306
    sql_query       = select  id,title,content from  fts_index    sql_ranged_throttle    = 0
}

index search{
    source = main
    path = /usr/local/coreseek/ var /data/search
}

　　

2. 测试数据(fts_index表里的数据是96664)

3. 创建索引。multi1和multi2分别索引了48332条记录，文档大小79.3+78.7=158m

 

一次创建所有的96664，总大小158m

3. 开启searchd服务，基于之前的应用，用ab做压力测试（ab -n 10 -c 10http://192.168.1.120:8000/search/?all_in=天堂）。rps是13.84。而在这期间，我机器上2颗cpu的都标得很高。可见，确实用多核。（在客户端做查询的时候需要设置索引client.AddQuery(q,index),这里index为search）

 

单个index，rps6.06。在测试过程中，确实只有一颗cpu到过99%，另外一颗很稳定。

 测试结果很明显，利用了sphinx的分布式特性的完胜。整个过程内存变化不是太多，而cpu一般都能到99%。

 

 

#################################################################################

 

9.2.27. local

分布式索引 distributed index中的本地索引声明。可以出现多次， 可选选项，默认为空。

此设置用于声明分布式索引被搜索时要搜索的本地索引。全部本地索引会被依次搜索，仅使用1个CPU或核。要并行处理，可以配置searchd查询它自身（细节参考 Section 9.2.28, “agent” ）。可以为每个分布式索引声明多个本地索引。每个本地索引可以在其他分布式索引中多次引用。

示例：

local = chunk1
local = chunk2

9.2.28. agent

分布式索引（distributed index）中的远程代理和索引声明。可以出现多次，可选选项，默认为空。

此设置用来声明搜索分布式索引时要搜索的远程代理。代理可以看作网络指针，它指定了主机、端口和索引名。在最基本的情况下，代理可以与远程物理主机对应。更严格的来说，这不一定总是正确：可以将多个代理指向同一台远程主机，甚至指向同一个searchd实例（以便利用多个CPU或核）

值的格式如下：

agent = specification:remote-indexes-list
specification = hostname ":" port | path

“hostname”是远程主机名，“port”是远程TCP端口，而“remote-index-list”是一个逗号分隔的远程索引列表。

全部代理会被并行搜索。然而同一个代理的多个索引是依次搜索的。这使您可以根据硬件来优化配置。例如，如果两个远程索引存储在一个相同的硬盘上，最好是配置一个带有多个按顺序搜索的索引，避免频繁的磁头寻址。如果这些索引存储在不同的硬盘上，那配置两个代理会更有利，因为这可以使工作完全并行。对于CPU也是如此，虽然在两个进程间切换对性能的影响比较小而且常常被完全忽略。

在有多个CPU和硬盘的机器上，代理可以指向相同的机器以便并行地使用硬件，降低查询延迟。并不需要为此设置多个searchd实例，一个实例与自身通信是合法的。以下是一个示例设置，它是为一台有4个CPU的机器准备的，可以并行地使用4个CPU，各处理一个查询：

index dist
{
	type = distributed
	local = chunk1
	agent = localhost:9312:chunk2
	agent = localhost:9312:chunk3
	agent = localhost:9312:chunk4
}

注意其中一块是本地搜索的，而同一个searchd示例又向本身查询，以便并行地启动其他三个搜索。

示例：

agent = localhost:9312:chunk2 # contact itself
agent = /var/run/searchd.s:chunk2
agent = searchbox2:9312:chunk3,chunk4 # search remote indexes

9.2.29. agent_blackhole

分布式索引（ distributed index）中声明远程黑洞代理。多个值，可选选项，默认是空。于版本0.9.9-rc1引入。

agent_blackhole 选项使用户可以向远程代理发送“即发即忘”的查询（fire-and-forget queries）。这在调试（或者仅仅是测试）即将投入生产的集群的时候很有用：可以设置一个单独的调试/测试searchd实例，然后从实际生产中使用的主服务器（master，或称聚集者aggregator）实例向这个测试服务器转发查询请求，但不干扰生产系统的工作。主（master）searchd会以正常的方式尝试连接和查询黑洞代理，但是它既不会等待也不会处理黑洞代理的反馈。同时，发生在黑洞代理上的全部网络错误也都被忽略。值的格式与普通的 agent 完全相同。

示例：

agent_blackhole = testbox:9312:testindex1,testindex2

9.2.30. agent_connect_timeout

远程代理的连接超时时间，单位为毫秒。可选选项，默认为1000（即1秒）。

连接到远程代理时，searchd最多花这些时间等待connet()调用成功完成。如果达到了超时时间connect()仍没有完成，而 and retries 选项是启用的，那么将开始重试。

示例：

agent_connect_timeout = 300

9.2.31. agent_query_timeout

远程代理查询超时时间，以毫秒为单位。可选选项，默认为3000（即3秒）。

连接后，searchd最多花这这些时间等到远程查询完成。这个超时时间与连接超时时间是完全独立的。因此一个远程代理最多能造成的延迟为agent_connection_timeout与agent_query_timeout之和。如果超时时间已到，查询不会再重试，同时产生警告。

示例：

agent_query_timeout = 10000 # our query can be long, allow up to 10 sec