Geeky question
 

For those of us involved in the technical side of making The Intarweb work, could someone tell us some information about the hardware, software and connectivity that makes FT what it is today?

How many servers are handling this load?
What functions have servers dedicated to them? (eg, mail servers, image servers, web/app servers, index servers, db servers, etc)
What configurations are they?
What are the disk subsystems?
What OSes are they running?
What databases?
What load balancing system is used?
Anything other info?

trial by geekery
 

I don't work at webflyer, but the frontend is running Linux, and presumably PHP to support vbb. Dunno what the webserver is--can't get a good fingerprint (and neither can the Netcraft folks, which is odd).

I'd bet a plugged nickel that the database is mysql.

Indeed it doesn't for www.flyertalk.com, but for just flyertalk.com it shows Apache 1.3.29. Go figure.

gav$ telnet www.flyertalk.com 80
Trying 64.78.185.92...
Connected to www.flyertalk.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 02 Apr 2004 23:55:21 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.3
Connection: close

I'll see if we can help you a little. I don't fully understand all the geeky stuff but will try to help. We're running PHP/MySQL on the back end. There are three dedicated servers to FT on a co-lo where we have half a rack. The three servers are ProLiant DL360 G3's with processor upgrades, 2 gb of memory and each has 2 - 72.8gb Ultra hard drives. One of them runs as a member db and the other two as web servers splitting the load balancing. There's more answers to your questions and i'll try and have the guys answer them.

I think you'll undertand we have invested in the hardware for FT, it just needs a few bugs in our optimization to be worked out. We found one in the load balancing today and it helps a little. We have some bad memory we're swapping out ans a few other things. In the next few days, you'll be enjoying what we really had planned for you all.

Thanks for the question and thanks for your support of FlyerTalk.

I'll see if we can help you a little. I don't fully understand all the geeky stuff but will try to help. We're running PHP/MySQL on the back end. There are three dedicated servers to FT on a co-lo where we have half a rack. The three servers are ProLiant DL360 G3's with processor upgrades from 2.4ghz, 2 gb of memory and each has 2 - 72.8gb Ultra hard drives. One of them runs as a member db and the other two as web servers splitting the load balancing. There's more answers to your questions and i'll try and have the guys answer them.

I think you'll undertand we have invested in the hardware for FT, it just needs a few bugs in our optimization to be worked out. We found one in the load balancing today and it helps a little. We have some bad memory we're swapping out ans a few other things. In the next few days, you'll be enjoying what we really had planned for you all.

Thanks for the question and thanks for your support of FlyerTalk.

Gotta love the double post. You're probably trying to rack up the postcount ala PremEx. =)

If you guys run into any issues and want some help, on any level, please look us up. This site has been an invaluable resource to me, and I'm glad to put my resources to work for you.

So if I understand correctly, the whole of Flyertalk is running on 3 machines which are about the same spec as a standard desktop computer these days?

No wonder it's slow!

Are you sure you've got your dimensioning calculations right?

James doesn't get enough sleep as it is... :p

Sorry. You must have me confused with some other post-count whore. I could give a flying F about post count.

Man, I wish that was the spec of my desktop. .

Aww. *huggles* Your post count is just an indicator of your dedication to the FF life and the FT community.

Funny how a boring thread got a small handful of replies in the middle of the night. Probably the only time of day that the boxes were able to handle the load. =)

I'd love to let Jamebus poke around..... He could find 10 minutes in his day for it. Just a bit more time than emailing a FedEx label would take. =)

You obviously don't know what you are talking about. ;)

Desktop PC's are awfully overpowered and can not be compared to dual Xeon machines with server architecture boards. At my Co-lo we run loads heavier than FT on machines with lower specs. Besdies that, desktop PC's run Windows and this server runs linux, MAJOR difference.

Your average desktop machine these days, with fast disks, running Linux and Apache and not much else, would probably serve a decent sized web site while using 1% of its resources. Desktop machines have oodles of CPU power available, which only people like Microsoft and games makers manage to slurp up with their bloatware.

Also, when Randy referred to Ultra hard drives, I assume he means SCSI. My ancient 4GB SCSI drives still perform as well as current IDE drives in general use, despite the IDE proponents' (general cheap drive makers) claims to the contrary.

Randy, is there any good reason why your web server machines don't have NTP on them? Having the board's time 5 mins wrong some of the time, 71 mins wrong now, is just amazing, given that the technology to have the time correct has been around for years, is totally trivial to set up, and prevents sys admins having to spend their time (mis-)setting the system clocks.

Here's my 2 cents......obviously I know nothing of the FT DB design and may be way wide of the mark but if a customer came to me with a DB based system running a bit slow this is the first place I would look......


My gut reaction is the DB server is disk I/O constrained. SCSI disks are fast but if you only have a couple of them (presumably mirrored) you have very limited I/O.

My background is mainly Microsoft however the fundementals of Databases and storage design are presumably pretty similar if you compare, say, SQL 2000 with Linux/MySQL

So....in Microsoft land we would always look to do the following basics to ensure optimum performance with a complex DB (rules of thumb in order of importance)

1 - Seperate the transaction logs from the main DB. Running transaction logs on seperate spindles usually yields significant performance benefits. A serial stream of write activity contends very badly with the completely random I/O of DB access so seperate them!

2 - Turn on Write caching, don't bother with read caching. You can't really do read ahead cache with a DB - data is typically requested from blocks randomly spread all over the place. For this reason, Write ahead caching is very important. You don't want to be waiting for a write operation to complete to disk before moving to the next I/O. (For DL360's you need to buy and install a Battery Backed Write Cache widget to accomplish this)

3 - Put your DB on as many (fast 15k) spindles as you can afford.

4 - If you have a lot of Write activity on your DB, avoid RAID 5, use RAID 1+0 instead.

5 - Stick TembDB on yet another seperate spindle if lots of queries are creating a lot of activity on TempDB (don;t know what the MYSQL equivilant is)


I don't know whether the FT DB is trivial and small or large and complex. If the latter then I think storage design is going to dictate performance.

There's a good whitepaper on all this here: http://h71019.www7.hp.com/ActiveAnsw...0-225-1,00.htm - quite MS SQL centric (isn't everything!) but a good read for those with a technical interest in this sort of stuff!

(Edited to add - sorry if this post goes slightly OT and more toward "what can we do to make FT faster" - I'm sure the team at FT are doing a great job with this major upgrade - I just wanted to re-iterate there are a bunch of people out here who use FT on a regular basis who are happy to do whatever they can to help out)