Date: Sat, 13 Oct 2001 00:01:26 -0400 From: "Haapanen, Tom" <tomh@metrics.com> To: "'Sean Chittenden'" <sean@chittenden.org> Cc: Marcel Prisi <marcel-lists@virtua.ch>, Scott Gerhardt <scott@gerhardt-it.com>, freebsd-isp@FreeBSD.ORG Subject: RE: PostgreSQL & shared memory Message-ID: <6B3C6B6F7AA2D511A35E0080C86993435982@syncro.metrics.com>
next in thread | raw e-mail | index | archive | help
>> - 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6B3C6B6F7AA2D511A35E0080C86993435982>