{"id":983,"date":"2019-10-28T07:00:34","date_gmt":"2019-10-28T11:00:34","guid":{"rendered":"http:\/\/192.168.1.39\/?p=983"},"modified":"2024-06-04T21:23:08","modified_gmt":"2024-06-04T21:23:08","slug":"web-server-logs","status":"publish","type":"post","link":"https:\/\/smcllc.smcwpsites.com\/blog\/web-server-logs\/","title":{"rendered":"Web Server Logs Are Stuck In the 90’s!"},"content":{"rendered":"

W3C Compliance<\/h2>\n

Web server logs suck! Every W3C compliant web server is supposed to have a \u201ctime taken\u201d field available to reveal how long the web server took to process\/serve a resource. However, by default, Apache and many other UNIX based web servers do not have good logging options for performance timings. NGINX and Litespeed pretty much adopt the Apache defaults. Typically the defaults aren’t the best choices for a load testing situation.<\/p>\n

When I look at the numbers produced in the web server logs, I realize they aren’t even the full story. It is only a measurement of the web servers response time, and does not indicate the full browser rendering time. However, it is useful to have these metrics to compare WITH full browser rendering. Let\u2019s first look at the default NCSA extended\/combined log format:<\/p>\n

“%h %l %u %t \\”%r\\” %>s %b \\”%{Referer}i\\” \\”%{User-agent}i\\”<\/p>\n

This standard was first released in 1993, and is based on a discontinued web server called HTTPd developed by the National Center for Supercomputing Applications, a unit of the University of Illinois at Ubana-Champaign. Many of the formatting codes are still relevant for logging. However, as we look deeper we see a glaring omission is the absence of a performance timing. I find this hard to believe. Wouldn’t most web server administrators want to know, at least at a basic level, the kind of performance metrics the web server is producing? The Apache web server formatting codes come from from a specific Apache module called \u201cmod_log_config\u201d. This is the code used to create the logs. We can find all of the latest codes and what they mean here:<\/p>\n

https:\/\/httpd.apache.org\/docs\/2.4\/mod\/mod_log_config.html<\/a><\/p>\n

Outdated Defaults<\/h2>\n

As we start matching the standardized codes to their descriptions, we can begin to understand what the access.log produced by the module reveals. The second format code is %l, which is \u201cRemote logname (from identd, if supplied). This will return a dash unless mod_ident is present and IdentityCheck is set On.\u201d The problem here is that ident and identd represent a protocol that is no longer being used by the majority of web applications.<\/p>\n

https:\/\/en.wikipedia.org\/wiki\/Ident_protocol<\/a><\/p>\n

There are many reasons it isn\u2019t being used today versus in 1993, including for security reasons. The use of the %l code is probably not very useful for today\u2019s access.logs. My suggestion is to replace this useless flag with one that will be used. There are a few performance related codes available to us:<\/p>\n