Apache的Access Log有什么作用

access_log為訪問日志,記錄所有對apache服務(wù)器進行請求的訪問,它的位置和內(nèi)容由CustomLog指令控制,LogFormat指令可以用來簡化該日志的內(nèi)容和格式

訪問日志

在Apache的Access Log中會看到很多如下的訪問日志：

127.0.0.1 - - [05/May/2011:10:54:07 +0800] "OPTIONS * HTTP/1.0" 200 -
127.0.0.1 - - [05/May/2011:10:54:08 +0800] "OPTIONS * HTTP/1.0" 200 -
127.0.0.1 - - [05/May/2011:10:54:09 +0800] "OPTIONS * HTTP/1.0" 200 -
127.0.0.1 - - [05/May/2011:10:54:10 +0800] "OPTIONS * HTTP/1.0" 200 -

這是什么意思呢？

Apache的文檔的說明

Apache的文檔中， 有如下的說明：

When the Apache HTTP Server manages its child processes, it needs a way to wake up processes that are listening for new connections. To do this, it sends a simple HTTP request back to itself. This request will appear in the access_log file with the remote address set to the loop-back interface (typically 127.0.0.1 or ::1 if IPv6 is configured). If you log the User-Agent string (as in the combined log format), you will see the server signature followed by “(internal dummy connection)” on non-SSL servers. During certain periods you may see up to one such request for each httpd child process.

可是，為什么要喚醒呢？ 喚醒是為了做什么呢？

在Apache Prefork模式下， 啟動的時候，Apache就會fork出一些worker進程， 來準(zhǔn)備接受請求， 這些worker進程，在完成準(zhǔn)備工作以后， 就會進入block模式的監(jiān)聽沉睡中， 等待請求到來而被喚醒。

另外一方面， 在Prefork模式下， 當(dāng)請求很多， 目前的worker進程數(shù)不夠處理的時候， 就會額外再fork一些worker進程出來， 以滿足當(dāng)前的請求。

而在這些請求高峰過后， 如果額外fork出來的進程數(shù)大于了MaxSpareServers， Apache就會告訴這些worker進程退出， 那么問題就來了。

這些進程都在沉睡中啊， 怎么告訴他們， 并且讓他們自我退出呢？

自我退出

Apache會首先發(fā)送一個退出狀態(tài)字(GRACEFUL_CHAR !)給這些Work進程：

static apr_status_t pod_signal_internal(ap_pod_t *pod)
{
   apr_status_t rv;
   char char_of_death = '!';
   apr_size_t one = 1;

   rv = apr_file_write(pod->pod_out, &char_of_death, &one);
   if (rv != APR_SUCCESS) {
       ap_log_error(APLOG_MARK, APLOG_WARNING, rv, ap_server_conf,
                    "write pipe_of_death");
   }

.    return rv;
}

但此時， Worker進程不會去讀這些狀態(tài)字， 因為他們還在沉睡。

這個時候Apache就會發(fā)送一個OPTIONS請求給自己， 喚醒這些沉睡的進程：

static apr_status_t dummy_connection(ap_pod_t *pod)
{
//...有省略
   /* Create the request string. We include a User-Agent so that
    * adminstrators can track down the cause of the odd-looking
    * requests in their logs.
    */
   srequest = apr_pstrcat(p, "OPTIONS * HTTP/1.0\r\nUser-Agent: ",
                          ap_get_server_banner(),
                          " (internal dummy connection)\r\n\r\n", NULL);
//...有省略
}

這些進程在處理完當(dāng)前請求以后(OPTIONS請求)， 就會發(fā)現(xiàn)， oh， 主進程讓我退出。

static void child_main(int child_num_arg)
{
//...有省略

   while (!die_now && !shutdown_pending) {
//...有省略
       //1. listen
       //2. accept
      //3. process request

       /* Check the pod and the generation number after processing a
        * connection so that we'll go away if a graceful restart occurred
        * while we were processing the connection or we are the lucky
        * idle server process that gets to die.
        */
       if (ap_mpm_pod_check(pod) == APR_SUCCESS) { /* selected as idle? */
           die_now = 1;
       }
//...有省略
  }
//...有省略
}