How do I measure connection rate?
ie. today in the span of 3 hours I have 5245 connections.
I have a mix of simple/short and complex/long SPs. So running from 1-15sec.
Any suggestions on settings?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at my connections on SQL server, it seems like one connection was taking all the resources blocking the other processes from running.
I have switch odbtp_connect to odbtp_sconnect in hopes that there will be more discrete connections for each query. it might be slower but at least one process won't block another.
I did notice that connections with sconnect seems to trim whitespace from the end of the results automatically. (This is when I return XML from the database) Any ideas?
Thanks again for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The connection rate can be estimated using the odbtpsrv.log file. Just count the number of OPEN's during a specific time period. YOu can get an idea of how long it is taking to service a connection by calculating the time difference between an OPEN and its corresponding CLOSE.
Does this app perform more of the long / complex transactions than it does the short / simple? Too many simultaneous long / complex transactions may result in a bottleneck either with SQL Server or the ODBC infrastructure. Sometimes reducing the value for MaxActiveClientThreads will improve performance. This is because it will prevent SQL Server or ODBC from being overloaded. You may also want to specify value for QueryTimeout to prevent "query hangs."
-- bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am getting this error when server gets busy:
[ODBTPERR][0]Unable to read from server (Success)
Specs:
Use PHP 5.2.4, ODBTP 1.1.4
SQL Server 2005 (Windows 2003)
2x Dual Core 3.0GHz Xeons, 6GB RAM
I reduced MaxActiveClientThreads to 32, and increased ReadTimeout to 3600.
We are running Stored Procedures exclusively.
[Settings]
;LogFile=odbtpsrv.log
;EnableLog=1
;LogReadAndSent=0
;LogODBC=0
;Port=2799
;ListenBacklog=32
MaxClientThreads=512
MaxActiveClientThreads=32
;ClientThreadWaitTimeout=60
ReadTimeout=3600
;TransBufferSize=4096
MaxRequestSize=10000000
ConnPoolSize=64
;ConnPoolTimeout=300
ReservConnPoolSize=24
;ReservConnPoolTimeout=3600
;BadConnCheck=0
MaxQrysPerConn=4
;ConnectTimeout=0
;QueryTimeout=0
;FetchRowCount=64
;EnableProcCache=0
What is your connection rate in seconds? What type of transactions are you performing? Are they simple and short or complex and long?
-- bob
How do I measure connection rate?
ie. today in the span of 3 hours I have 5245 connections.
I have a mix of simple/short and complex/long SPs. So running from 1-15sec.
Any suggestions on settings?
Looking at my connections on SQL server, it seems like one connection was taking all the resources blocking the other processes from running.
I have switch odbtp_connect to odbtp_sconnect in hopes that there will be more discrete connections for each query. it might be slower but at least one process won't block another.
I did notice that connections with sconnect seems to trim whitespace from the end of the results automatically. (This is when I return XML from the database) Any ideas?
Thanks again for your help.
The connection rate can be estimated using the odbtpsrv.log file. Just count the number of OPEN's during a specific time period. YOu can get an idea of how long it is taking to service a connection by calculating the time difference between an OPEN and its corresponding CLOSE.
Does this app perform more of the long / complex transactions than it does the short / simple? Too many simultaneous long / complex transactions may result in a bottleneck either with SQL Server or the ODBC infrastructure. Sometimes reducing the value for MaxActiveClientThreads will improve performance. This is because it will prevent SQL Server or ODBC from being overloaded. You may also want to specify value for QueryTimeout to prevent "query hangs."
-- bob