Connections to PHP LSAPI socket timing out under higher traffic

Discussion in 'Install/Configuration' started by eek, Jan 28, 2010.

  1. eek

    eek New Member

    Hi there,

    we are running version 3.3.14 with LSAPI php (php version: 4.4.9, LSAPI version: 4.1) we are hostin approximately 280 php domains and couple of rails applications (5 I think of which 3 are being frequented more) on a 2-CPU box with 4GB of RAM. Recently we started to run into connection timeouts to the lsapi php socket:

    Code:
    2009-12-20 13:35:34.066 [INFO] [65.55.106.210:48960-0#APVH_***:80] connection to [uds://tmp/lshttpd/global-php.sock] on request #24, error: Connection timed out!
    and connection resets

    Code:
    2010-01-28 09:26:42.014 [INFO] [12.32.232.44:11879-0#APVH_***:80] connection to [uds://tmp/lshttpd/global-php.sock] on request #13, error: Connection reset by peer!
    
    Connection timeouts are occurring only during high traffic, connection resets are present all the time. By high traffic I mean 100 concurrent connections.

    Could you please shed some light into how we could improve things so we wouldn't get into connection timeouts so easily?

    I am including some configuration:

    General
    Code:
    Priority:15
    Memory I/O Buffer:1G
    
    Tuning/Connection
    Code:
    Max Connections: 200
    Max SSL Connections: 100
    Connection Timeout (secs): 300
    Max Keep-Alive Requests: 20
    Smart Keep-Alive: Yes
    Keep-Alive Timeout (secs): 5
    Send Buffer Size (bytes): 0
    Receive Buffer Size (bytes): 0
    
    Security/External Application Resource
    Code:
    CPU Soft Limit (sec):300
    CPU Hard Limit (sec):600
    Memory Soft Limit (bytes):500M
    Memory Hard Limit (bytes):600M
    Process Soft Limit:50
    Process Hard Limit:50
    
    LSAPI PHP
    Code:
    Name	: global-php
    Address: uds://tmp/lshttpd/global-php.sock
    Notes	: Not Set
    Max Connections: 200
    Environment: LSAPI_CHILDREN=200, LSAPI_MAX_REQS=100, LSAPI_MAX_IDLE=20, LSAPI_MAX_IDLE_CHILDREN=1
    Initial Request Timeout (secs): 300
    Retry Timeout (secs): 0
    Persistent Connection: Yes
    Connection Keepalive Timeout: 5
    Response Buffering: No
    Auto Start: Yes
    Command: $SERVER_ROOT/fcgi-bin/lsphp
    Back Log: 100
    Instances: 1
    Run On Start Up: Yes
    Max Idle Time: 20
    Priority: Not Set
    Memory Soft Limit (bytes): 300M
    Memory Hard Limit (bytes): 500M
    Process Soft Limit: 80
    Process Hard Limit: 100
    
    Thank you!
  2. mistwang

    mistwang LiteSpeed Staff

    time to upgrade to latest LSWS 4.0.12 with latest LSAPI.
  3. eek

    eek New Member

    Thanks for the reply, but besides the upgrade (I haven't found any mention of this behavior in the server release log), do you have any additional advice regarding the configuration that would help reduce these connection problems?

    Thank you!

    Andrej
  4. mistwang

    mistwang LiteSpeed Staff

    You should increase

    Memory Soft Limit (bytes): 500M
    Memory Hard Limit (bytes): 600M
    Process Soft Limit: 800
    Process Hard Limit: 1000
  5. anewday

    anewday Moderator

    I thought those log entries are normal.

    LSAPI_MAX_REQS=100

    Could it be due to the above?
  6. eek

    eek New Member

    We found another interesting fact. LSAPI PHP processes are having quite high disk I/O. Most of the I/O actions was dirtying nodes, but what puzzled me a bit was that there were static files (mostly pictures) being touched by LSAPI PHP process. That brings me to a question are we serving static files through LSAPI PHP ? That shouldn't be the case since only .php suffix is setup to be handled by LSAPI PHP.

    Just to clarify we are using PLESK and Litespeed as a replacement for Apache. Is there a need for rewrite rules in order to not serve static content through php process?

    All other files referenced by the I/O activity were .php files. That brings me to another question. Would this activity lower if we used opcode cache ?

    Thank you!

    Yes I would imagine that Connection Resets are being caused by the request limit. I am more concerned about the Connection Timeouts.

    Andrej
  7. NiteWave

    NiteWave Administrator

    should not. how do you come to this conclusion?

    have you upgraded to 4.0.12, or still be 3.3.24?

    LSAPI_MAX_REQS=100

    looks too small. how about 1000, 5000?

Share This Page