Does this only happen under heavy load? You might be able to adjust
your init.tcl to handle more connections. I'm not sure what you would
need to change so I pulled out any config that might help.
-Tony
ns_section "ns/parameters"
ns_param listenbacklog 32 ;# Max length of pending conn queue
# keepalivetimeout
# In prior versions of AOLserver this may have been under
# ns/servers/$server. Set to 0 to disable Keep-alive support, any other
# value will enable Keep-alive but won't actually configure the timeout,
# which is now configured under the driver.
# (http://aolserver.am.net/docs/tuning.adpx)
ns_param keepalivetimeout 30 ;# Max time conn is kept alive
(keepalive)
# maxkeepalive
# In prior versions of AOLserver this may have been under
# ns/servers/$server. In AOLserver 4.0 and newer, this setting exists
# but appears to be non-operational
# (http://aolserver.am.net/docs/tuning.adpx)
ns_param maxkeepalive 100 ;# Max no. of conns in keepalive
state
ns_section "ns/server/${server_name}"
ns_limits set default -maxrun 500 ;# the maximum number of
connections which can be running simultaneously
### Tuning Options ###
ns_param connsperthread 0 ;# Normally there's one conn per
thread
#ns_param flushcontent false ;# Flush all data before
returning
ns_param maxconnections 100 ;# Max connections per
connection thread before it is shut down
#ns_param maxdropped 0 ;# Shut down if dropping too many conns
ns_param maxthreads 20 ;# Tune this to scale your server
ns_param minthreads 0 ;# Tune this to scale your server
ns_param threadtimeout 120 ;# Idle timeout for connection
threads
ns_param spread 20 ;# Variance factor for
threadtimeout and maxconnections to prevent mass mortality of theads
(e.g. +-20%)
ns_section "ns/server/${server_name}/module/nssock"
ns_param Address $address
ns_param Hostname $host
ns_param Port $port
ns_param maxsock 500
ns_param keepwait 30 ;# number of seconds to hang-up on
clients while waiting for connection
ns_param socktimeout 30 ;# number of seconds to wait for a
client request. increase for file upload
ns_param maxinput 1MB ;# maximum size of data sent from browser
ns_param maxline 16k ;# maximum number of bytes for http
request or header line.
ns_param maxheader 64k ;# maximum number of bytes for all
HTTP header lines in a request
########################################################################
# Thread library (nsthread) parameters
#
# If the server is crashing with no explanation you may have a corrupted
# data due to a stack overflow. Calculate locally declared data types
# and function parameters to get the stack size needed.
########################################################################
ns_section "ns/threads"
#ns_param mutexmeter true ;# measure lock contention
#ns_param stacksize [expr 128*1024] ;# stack size per thread (in
bytes)
On 8/26/14, 9:05 AM, Cyan ogilvie wrote:
> Hi
>
> I'm hoping there are still some subscribers to this list ;)
>
> I'm trying to debug a strange condition we're seeing on a small
> percentage of our connections: connections are being closed by the
> server without any response being sent back on the connection
> (verified by looking at network packet traces and inserting a logging
> transparent proxy between the client and server). The network packet
> pattern we see is:
>
> <normal TCP setup - SYN, SYN/ACK, ACK>
>
> Request data (in a single frame, or multiple), ACK
>
> Then the connection is closed by the server after 10 - 70 ms, without
> any data being sent, with a FIN/ACK (still getting confirmation on
> this - these logs are from the other side of the man-in-the-middle
> proxy I'm using to get debugging info).
>
> For some of the failed requests, the server processing never gets as
> far as the start of our Tcl code (a preauth filter that starts with an
> ns_log that doesn't show up in the server log).
>
> For others the request is processed normally and an access.log message
> written indicating that a response was generated with HTTP code 200,
> but no packet shows up on the network.
>
> There is no pattern to the failed requests (sometimes requests for
> favicon.ico fail), and retrying the exact request shortly afterwards
> often succeeds.
>
> Has anyone seen anything like this before, or have any advice on how
> to narrow down the cause further?
>
> We're running a slightly patched version of the last 4.5.2 rc, on
> Ubuntu 12.04.5 64bit on Amazon EC2 instances, with Tcl 8.6.1
>
> Thanks
>
> Cyan
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
>
>
> _______________________________________________
> aolserver-talk mailing list
> aolserver-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/aolserver-talk
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk
