I figured that was probably the case.
As I said, it's just a habit formed many years ago to reduce the surface area for problems. There's a reason that 'turn it off and back on' is in the first lessons of tech support 101.
Code:uts 1d 07:45 process uptime log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5) kcc 1 number of active service threads kmx 30 maximum number of service threads kvg 2.69 average number of requests per service thread krq 105 max number of requests by one service thread req 6702 total # of requests (HTTP, HTTPS, success, failure etc) avg 1706 bytes average size of requests rmx 21740 bytes largest size of request(s) tav 9 ms average processing time (per request) tmx 10003 ms longest processing time (per request) slh 2584 # of accepted HTTPS requests slm 301 # of rejected HTTPS requests (missing certificate) sle 0 # of rejected HTTPS requests (certificate available but bad) slc 235 # of dropped HTTPS requests (client disconnect without sending any request) slu 140 # of dropped HTTPS requests (unknown error) sct 97 ssl cache: # of cached cert sch 1482 ssl cache: # of cache hit scm 97 ssl cache: # of cache miss scp 0 ssl cache: # of purge to free up slots
End users are always right. I don't do end users for work and I'll leave the authority opinion to others Instead, let's check your latest servstats numbers. Always impressive!