Re: [AOLSERVER] Null responses

[Tony B. (B. P. Tickets) <to...@br...>]

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
> aol...@li...
> https://lists.sourceforge.net/lists/listinfo/aolserver-talk