From owner-freebsd-isp Sat Jul 26 03:27:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA23735 for isp-outgoing; Sat, 26 Jul 1997 03:27:48 -0700 (PDT) Received: from mail.id.net (mail.id.net [199.125.1.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA23729 for ; Sat, 26 Jul 1997 03:27:40 -0700 (PDT) Received: from server.id.net (server.id.net [199.125.2.20]) by mail.id.net (8.8.6/8.8.6) with ESMTP id GAA00324; Sat, 26 Jul 1997 06:28:31 -0400 (EDT) From: Robert Shady Received: (from rls@localhost) by server.id.net (8.8.5/8.7.3) id GAA21284; Sat, 26 Jul 1997 06:28:21 -0400 (EDT) Message-Id: <199707261028.GAA21284@server.id.net> Subject: Re: analog and Apache? In-Reply-To: from spork at "Jul 26, 97 01:35:14 am" To: spork@super-g.com (spork) Date: Sat, 26 Jul 1997 06:28:21 -0400 (EDT) Cc: sysop@mixcom.com, jas@flyingfox.com, freebsd-isp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > There is another problem with this as well. If a site has a very large > > logfile, 10 Mb, 100 Mb, or more even, Analog will start using a lot of > > memory. Once the server starts swapping it takes a bit of a performance > > hit. Not to mention that it was thrashing our name servers. > > Hmmm... Haven't seen this here, even on 200M files as long as the server > is not overloaded. We set resolv.conf on the webservers to look at one of > our little-used secondaries, so the deluge of DNS requests will not affect > our two main nameservers. I haven't really seen this touch the load on > the nameserver, though. Also, analog sets up a cache, so you'll see over > a period of time the logs take less time to crunch. The current analog is > very efficient, and other than a mind-spinning array of command line > switches, it's fairly easy to tweak to your liking... > > > Personally I find that FBSD and Apache work well together and with tweaking > > and ample memory you can handle a lot of traffic. The "savings" of not > > logging IP was non-exisistant. Hmmm.. We log DNS lookups, perhaps you guys are just "lucky" in a sense, but these are a couple of our logfiles (we have several like this), and these are about 200-300MB smaller than "normal" since they haven't been promoting their website for a while now. -rw-r--r-- 1 nobody nogroup 540540984 Jul 26 06:13 access_log -rw-r--r-- 1 nobody nogroup 584473315 Jul 26 06:14 access_log And let me tell you... Going through more than # wc -l access_log 2592183 access_log requests and processing DNS lookups AFTER the fact is a complete pain in the rump and DOES have an impact on DNS machines, the network, etc. We haven't really noticed too many problems with real-time DNS lookups. What *SHOULD* be done (perhaps it already is) is that the logging trail behind the incoming requests and the DNS lookups be done at the webservers convience, but as close to real-time as possible so as not to slow down any interactive connections.. -- Rob === _/_/_/_/_/ _/_/_/_/ _/_/ _/ _/_/_/_/_/ _/_/_/_/_/ _/ _/ _/ _/_/_/ _/ _/ _/ _/_/_/_/ _/ _/_/_/_/_/ _/_/_/_/ _/ _/ _/_/_/_/_/ _/ Innovative Data Services Serving South-Eastern Michigan Internet Service Provider / Hardware Sales / Consulting Services Voice: (810)855-0404 / Fax: (810)855-3268 / Web: http://www.id.net