Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 9293 invoked from network); 12 Feb 2004 15:30:38 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 12 Feb 2004 15:30:38 -0000 Received: (qmail 90900 invoked by uid 500); 12 Feb 2004 15:30:15 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 90886 invoked by uid 500); 12 Feb 2004 15:30:14 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 90864 invoked from network); 12 Feb 2004 15:30:14 -0000 Received: from unknown (HELO dessent.net) (66.227.14.169) by daedalus.apache.org with SMTP; 12 Feb 2004 15:30:14 -0000 Received: from [127.0.0.1] (helo=dessent.net) by dessent.net with esmtp (Exim 4.30) id 1ArIqN-00051E-Pg for users@httpd.apache.org; Thu, 12 Feb 2004 15:33:36 +0000 Message-ID: <402B9BBE.696DC318@dessent.net> Date: Thu, 12 Feb 2004 07:29:02 -0800 From: Brian Dessent Organization: My own little world... X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,en-US MIME-Version: 1.0 To: users@httpd.apache.org References: <20040212131509.22672.qmail@web41106.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Subject: Re: [users@httpd] *.shtml or *.html X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Ben Crane wrote: > In terms of overhead, is it really a threat to speed > as websites get bigger (I mean this one will never > grow in excess of a 100 pages) or is that more of an > urban legend...I've tried the SSI on my pages, in > fact, my demo loads a fairly complex webpage into a > webpage and it seems to not represent too much of an > overhead. The number of pages on the site isn't really relevant. What matters is the rate of hits that Apache must service that require parsing. If you're getting 50 hits per second that require parsing then it will take its toll in terms of CPU. However, if you're only averaging one page every 3 seconds then it will be hardly noticeable unless you're running this off an old 486 with 8MB ram or something. The more significant thing to realize is that if every page is generated with SSI then you're now running a 100% dynamic site, just as if every page was generated through PHP or Perl. That means that no pages will be cached, except for images of course. Normally, all of the static elements of a page are cached by the browser so that the next time that page is loaded, the web server can just respond with a "304 Not Modified" without retransmitting anything -- assuming that the page on disk hasn't changed. But with SSI and every other form of dynamic page generation, the server has no idea ahead of time whether the page has been modified or not and so it cannot respond with a 304, it has to serve every request in full. This will cause a lot more outgoing bandwidth if you have lots of hits for large HTML files that are being generated with SSI. Brian --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org