Planetarion Forums - I was quite surprised to see where planetarion was running on...

Structural Integrity · 27 Nov 2002, 17:37

Taken from this thread: http://pirate.planetarion.com/forum/...hreadid=154416

Quote:

Bandwidth:
5-6mbits (peak time) serving approx 1 Million pages per day
Peak info for busiest day: 21.420.353 kb, 1.824.117 pages
For October, we pushed 525GB of data over the internet link, 38Mill pages, 87Mill hits. 194.316 unique IP addresses accessed us.

Hardware:
1 * Fast dual processor database server with a scsi raid controller, running Sybase or MSSQL.
4-6 * Normal web servers PIII 500+ with 1 GB memory with large hard drive capacity, RedHat 6.2, with a 2.4.x kernel

Forums: Normal webserver with php, mysql, apache.
Alliance Hosting : Normal webserver with php, mysql, apache.
Portal: Normal webserver with php, mysql, apache

The bandwidth is sheer amazing IMO (I've never really seen any bandwidth stats, but I find that a LOT of data), yet the servers look miserable in contrast.
I expected a huge set of servers with dual and quad processor setups and incredible amounts of memory. But a few P3-500 and a heavier DB server is quite small for a game that used to host 180k players with a half-decent GUI.

Any comments on this?

Leshy · 27 Nov 2002, 17:45

Quote:

Originally posted by Structural Integrity
Any comments on this?

Several modern space satellites still use 486 processors.

Servers don't need to be that fast at all, tbh. All they need to do is receive requests, send replies and serve pages. A decent amount of memory and fast hard disk access are the main things on the hardware side. The limiting factor on a server is normally the bandwith, not any of the specs.

Structural Integrity · 27 Nov 2002, 17:59

Quote:

Originally posted by Leshy
Several modern space satellites still use 486 processors.

Servers don't need to be that fast at all, tbh. All they need to do is receive requests, send replies and serve pages. A decent amount of memory and fast hard disk access are the main things on the hardware side. The limiting factor on a server is normally the bandwith, not any of the specs.

Well, aren't the scripts tough on the servers? When serving 1.8mil pages on a day, loaded with information and variables I can think of quite some stress on those machines. Also the database machine.... only a dual processor machine?!

The funny part is that I recall Spinner posting anouncements about Fudge going to "headquarters" to fix the servers (when they burped again)... I can still see my own version of Fudge in my mind, standing amongst a set of huge cases with flickering lights, while in reality it was probably no more than a few midi towers aligned on a table.

wakey · 27 Nov 2002, 18:20

Nah the scripts wont take much processing power at all. As Leshy said its the bandwith (both externally to serve the page to the viewer and internally between the webserver and the db server) that causes causes any bottle necks. In fact most of the problems of pages not loading in the past were simply down to the db server not being able to serve the data to the webserver quick enough.

Back around r4 and r5 Fudge (or was it Vish) seemed to spend most of their time just twaeking the whole db aspect of teh game just to try and keep these bottleknecks ata mininum

Dave · 27 Nov 2002, 18:32

Quote:

Originally posted by wakey
Back around r4 and r5 Fudge (or was it Vish) seemed to spend most of their time just twaeking the whole db aspect of teh game just to try and keep these bottleknecks ata mininum

Vish was the DB man.

But the general impression that I got from people 'in the know' was that Vish coded a DB system for planetarion.

Aparently not.

So how many #linux people did they get to code the other scripts.

heh

27 Nov 2002, 18:37

I read somewhere that the game was coded in C - if this is the case then the processor power wouldn't be overly important in as it would run uber fast anyway.

As said above, the main causes of slowness is teh database and bandwidth.

meglamaniac · 27 Nov 2002, 18:38

Satelites on 486's is nothing.
Spaceshuttles still have thier software loaded in off tape.

Viva la USA!

BesigedB · 27 Nov 2002, 19:15

they need an upgrade to take advantage of the magical new MMX technology

wakey · 27 Nov 2002, 19:20

Quote:

Originally posted by Dave

Vish was the DB man.

But the general impression that I got from people 'in the know' was that Vish coded a DB system for planetarion.

Aparently not.

So how many #linux people did they get to code the other scripts.

heh

Coding a whole DB system would be a waste of time when there are systems already around that do it...theres little point reinenting the weel

djbass · 27 Nov 2002, 19:34

First thing to keep in mind is that as Dudels has already pointed out they are not scripts in the traditional sense.

The entire game from the ticker(s) to the CGI were programmed in C++ so as they are pre-compiled they use relatively low overhead.

Also, it uses Fast-CGI which as opposed to traditional CGI keeps itself loaded in memory the entire time so that it does not have to keep loading and unloading the code all the time to process the pages.

Also, the server setup has changed many times throughout PA's history. At one stage at least they had the ticker running on two seperate machines each one processing 1/2 the DB each.

I also seem to recall that when Barrysworld were doing the hosting they had significantly more webservers operating.

=[DJ Bass]=

queball · 27 Nov 2002, 21:13

Quote:

Originally posted by Dave

So how many #linux people did they get to code the other scripts.

Two.

Structural Integrity · 27 Nov 2002, 21:15

Quote:

Originally posted by queball

Two.

#linux coded PA scripts?
Which ones if I may ask?

Dave · 27 Nov 2002, 21:42

Why does that not suprise me

.

27 Nov 2002, 22:27

#linux are everywhere

Raging.Retard · 28 Nov 2002, 04:25

I too am suprised at those specs. To me they seem like complete overkill. My DB server is only a P3/900 with 1GB ram, and it does about 400 SQL queries per second. It spends most its time at about 10% load.

I also run a web server from the same machine, running pre-compiled pages. We run about 500k pages a day.

PA's specs seem slightly over powered in comparison.

mikay · 28 Nov 2002, 05:16

38 million pages per month = a stunning 10 per second .... over 6 web servers. A little over specced there.

The really wierd thing is they always used specific servers fro specific pages and never even tried load balancing which might have been an easy solution to some of the DOS attacks.

at0mic.c0w · 28 Nov 2002, 10:22

Quote:

Originally posted by mikay
38 million pages per month = a stunning 15 per second .... over 6 web servers. A little over specced there.

15 per second on average tho at peak times i'm sure the load is significantly higher

Gayle29uk · 28 Nov 2002, 10:32

Quote:

Originally posted by at0mic.c0w

15 per second on average tho at peak times i'm sure the load is significantly higher

That's the crucial point I think. The average might be 15/s but the peak load (at 06:55) will probably be 100 times that.

meglamaniac · 28 Nov 2002, 10:56

Gayle's right - you can't base something like this on the average load - you have to have the equipment to handle the peak times.
Think back to rounds 3 and 4 - there were constant problems with load at peak (hello military page timeouts) despite PA bringing in new kit.
This means the majority of the time you have some quite high performance machines sitting there doing nothing much, I know - but a buyer may well be running more than just PA, so this may ballance the processing commitment somewhat.

Leshy · 28 Nov 2002, 11:49

Quote:

Originally posted by Raging.Retard
We run about 500k pages a day.

Round 4, PA ran between 10 and 12 million pages a day.

mikay · 28 Nov 2002, 12:59

Quote:

Originally posted by meglamaniac
Gayle's right - you can't base something like this on the average load - you have to have the equipment to handle the peak times.
Think back to rounds 3 and 4 - there were constant problems with load at peak (hello military page timeouts) despite PA bringing in new kit.
This means the majority of the time you have some quite high performance machines sitting there doing nothing much, I know - but a buyer may well be running more than just PA, so this may ballance the processing commitment somewhat.

You won't be peeking massively more because PA has cycles and not everyone launches at 6.55 or 5.55 or at all really. Launching is only a few page accesses, it prolly takes more accesses to scan the target than launch on them.

Any problem stems from the fact npaweb02 serves mil screens and npaweb01/3/4/5/6 sit idly by while it is being pounded. Same with the resources screen 36 ticks in etc.