From owner-freebsd-isp Fri Oct 12 21: 6:22 2001 Delivered-To: freebsd-isp@freebsd.org Received: from omega.metrics.com (omega.metrics.com [204.138.110.1]) by hub.freebsd.org (Postfix) with ESMTP id 0713037B40B for ; Fri, 12 Oct 2001 21:06:17 -0700 (PDT) Received: from syncro.metrics.com (syncro.metrics.com [204.138.110.20]) by omega.metrics.com (8.9.3/8.9.3) with ESMTP id AAA27251; Sat, 13 Oct 2001 00:05:03 -0400 (EDT) Received: by syncro.metrics.com with Internet Mail Service (5.5.2653.19) id <4TAC843Y>; Sat, 13 Oct 2001 00:01:34 -0400 Message-ID: <6B3C6B6F7AA2D511A35E0080C86993435982@syncro.metrics.com> From: "Haapanen, Tom" To: "'Sean Chittenden'" Cc: Marcel Prisi , Scott Gerhardt , freebsd-isp@FreeBSD.ORG Subject: RE: PostgreSQL & shared memory Date: Sat, 13 Oct 2001 00:01:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> - Web server: Alpha 164SX/533, 320 MB, NetBSD 1.4 >> - Database server: P3/700, 512 MB, FreeBSD 4.3 > Few points (if you don't mind the criticism): > 1) Alpha on NetBSD? Why not FreeBSD? It should be faster, but you may > have some hardware needs that require it. I set this up in late 1999, when FreeBSD/Alpha was still pretty raw. NetBSD has been extremely stable, which is my #1 objective. :-) FreeBSD/Alpha may be fine now, but since the system isn't broken ... (The FreeBSD database server came later, when I finally came to realize that MySQL really, really didn't like NetBSD threads.) > 2) Splitting up the work between servers based on the application, while > nice, doesn't really utilize your resources correctly. If you can > cluster your webservers together at all, then that'd be the best thing > to do. I use mod_backhand to do this and I stick my PPro 200 right next > to a few dual K6's and PIII's and the cluster takes advantage of the > hardware when appropriate. Sure, yes. But dedicated functionality is clean and easy to maintain -- an important factor when I have limited time available. >> We haven't been clever about doing network buffering, but the web server >> does quite nicely, in spite of the 10 MB httpd processes. Only if the >> database server is not reachable does it start running out of memory. > Just think, you could increase your throughput by at least 20X just by > adding such a buffer... We need 20x the visitors first! :-) But, yes, it's something I will look at as traffic grows. But, on the other hand, I suspect I'll end up clustering the database server side first, as it's going to be CPU-bound fairly soon. >> On the database side, I think MySQL is lighter that PostgreSQL -- and it's >> threaded. I have a hard time getting it to use all the memory on the >> server. :-) > That's a religious debate in the making. :) It really depends on your > data and your application. If you're working with less than 3 tables in > any application and with data sets less than 500K, then MySQL is > faster... anything beyond that, however and you're into PostgreSQL land > (which isn't that much slower actually than MySQL: we're about to port > everything off of MySQL to Postgres because the speed difference is less > than 5% now). Could be. :-) Three tables in any one query? Yes, I suspect that's true of 90% of the queries. Most database tables are less than 1 MB, with the exception of our fulltext search table, which is about 300 MB. >> Our CPU utilization is low -- as long as you design your database and your >> SQL queries right. And this can really make a huge difference. Our front >> page (the most complex page on the site) takes about 1.5s to process, due to >> more than a dozen SQL queries. But before tuning it might have taken 10-20 >> seconds ... > Good point. If any of the data can be prejoined into a flat SQL table, > then you could get those load times down even further (at the cost of a > little disk space). If your application allows, yes. Our data is a little too dynamic for that ... Tom Haapanen tomh@motorsport.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message