这些天我正在做一些SQL调优,并在测试期间找到一个奇怪的SQL:
SELECT StatMan([SC0],[SC1], [SB0000])
FROM (SELECT TOP 100 PERCENT [SC0],[SC1], step_direction([SC0]) over (order by NULL) AS [SB0000]
FROM (SELECT [tableA] AS [SC0],[tableB] AS [SC1]
FROM [dbo].[url] WITH (READUNCOMMITTED,SAMPLE 3.408654e+000 PERCENT)
) AS _MS_UPDSTATS_TBL_HELPER
ORDER BY [SC0],[SC1], [SB0000]
) AS _MS_UPDSTATS_TBL
OPTION (MAXDOP 1)
Run Code Online (Sandbox Code Playgroud)
看起来这是根据SQL Server做一些"reindex"或"重建"一些db索引.但我的问题是,除了测试之前每个表的"reindex"之外,我们如何在长负载测试期间避免这种情况.
由于我的表包含足够的行,因此该SQL将消耗16862ms.我的测试中有很多插入动作.
当我们调用SOLR服务器时,我们遇到"连接重置"错误.而且我们的并发负载相当小.
这是SOLR的Tomcat连接器配置:
<Connector port="8983" protocol="HTTP/1.1"
connectionTimeout="20000" maxThreads="40000" minSpareThreads="400" maxSpareThreads="5000" maxKeepAliveRequests="100" URIEncoding="UTF-8"
redirectPort="8943" />
Run Code Online (Sandbox Code Playgroud)
这是我们从SOLR客户端得到的:
Caused by: org.apache.solr.client.solrj.SolrServerException: java.net.SocketException: Connection reset
at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:472)
at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:243)
at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89)
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:122)
... 36 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
Run Code Online (Sandbox Code Playgroud)
通过读取SOLR客户端代码进行故障排除后,我们发现这可能是由于SOLR的Tomcat配置中的连接超时设置不正确.我们决定将其更改为默认值(无限超时).所以,我的问题是,在将此值设置为无限时,是否会引发其他性能问题?
我发现apache xfire在其标题中添加了一个head参数:
POST /testservice/services/TestService1.1 HTTP/1.1
SOAPAction:"testAPI"Content-Type:text/xml; charset = UTF-8
User-Agent:Mozilla/4.0(兼容; MSIE 6.0; Windows NT 5.0; XFire Client + http://xfire.codehaus.org)
主持人:192.168.10.111 :9082
期望:100-continue
这个Expect:100-continue会在xfire客户端和它的端点服务器之间进行往返调用有点浪费,因为它会再使用一次握手让原始服务器返回"愿意接受请求"吗?
这只是我的猜测.
万斯
performance ×3
config ×1
http-headers ×1
java ×1
solr ×1
sql ×1
sql-server ×1
testing ×1
tomcat ×1
web-services ×1
xfire ×1