Hi Vic
Just wanted to add another perspective to the advice Bruce has already given.
Yours is potentially a very greedy system. You need to work out the specifications and metrics for all of the components that are required to make your application work. These are (at least):
- Ram required based on the number of concurrent threads
- CPU based on the number of concurrent threads
- Required disk IO rate
- High availability requirements
- Backup requirements
If the hardware that you deploy is not capable of meeting all of the these requirements then your application will fail.
The first thing you need to know for sure is the actual request rate. You said that the sites would log every 5-10 secs that's a spread of 2:1 so if you can't control the connection rate then you'll have to plan for 5 secs. Bruce has pointed the way to the arithmetic and it boils down to 100 requests per sec and you will need to support the Ram required by those 100 requests, the CPU capacity and the disk IO rate.
Actually, I think you will need up to three webservers (load balanced in some way) and depending on HA requirements, two DB servers - here's why.
You have to support at least 100 concurrent threads. If you look at the specs of an IBM System x3550 M4 Express server you will find that it two sockets (Intel 4C E5-2609) and each of these sockets has four cores and supports 4 threads for a total of 8 threads. This means that only eight of your 100 concurrent threads can execute at the same time which means that to do all of the processing for the 100 requests you have to get through each set of 8 in 0.08sec or 80 m seconds. The actual time is shorter than that because even though each core can support two threads they both cannot operate at the same time all of the time because the threads share the core's memory so its not as good as having eight single threaded cores.
But lets go with 80 msecs because this is just an example. For each thread you have 10 msecs or 1/100th sec to get the processing done. Bruce often quotes 1/10th sec pre request or thread which is 10x more than the time you've got. And that's if you are only doing CPU work - if you add IO then you've time for about 8 IOs for all of the 8 threads which is just 1 IO per thread.
This server could not support your load from a CPU perspective (we'll get to the Io later).
So the point is that this server does not support enough threads. Ideally you need to be able to support 100 concurrent threads and based on this server you would need 13 of them! But you do need to think about availability and if you can't have the web server dying (which means logging is lost) then you'll need at least two and if you can't have any data lost then you'll need enough servers to be able to do all of the work even though one server fails. There are a number of things to consider but this is about service, up time and availability.
Here are the considerations: if you deploy 1 web server that can handle the peak load and it dies then no work gets done. If you deploy two servers that together can handle the peak load and one dies then half of the work does not get done. If you can't afford those scenarios then you will need at least 2 servers configured so that 1 server can handle all of the load or 3 servers where 2 of them can handle the peak load (and trust that you won't have two server outages the overlap).
As Bruce has already said you will not be able to support the DB sizes using TopSpeed files (assuming the estimated data growth) so you will need MySQL or equivalent. Another reason for having a SQL DB is that you will need to do backup and the consideration here is whether the application and DB have to be available 24x7. If they do then you will need to be able to place the DB in 'hot backup' mode (an Oracle term I think) so that you can backup at a point in time while still processing. If you have the luxury of a period during the 24 hours when there is no work to do then you can take the application down and do the backup in peace. But remember that backup software consumes lots of CPU and disk IO resources which is another reason why you aren't going to get away with a single web server that does everything. And sometimes the backups would fail and have to be done during peak processing times!
So you'll need a separate DB server. Then the same availability questions as for the web server apply here. If you lose a single DB server then no work gets done no matter how many web servers you've got. So you'll need 2 if you can't afford to lose data. The DB layer now starts to get quite tricky and expensive and I won't go into it more other than to say that I would choose a Unix-based DB server which will be more stable than a Windows box and depending on your requirements you may be able to get away with 1 DB server. If you can't then clustering of the DB backend has to be considered and deeper pockets.
The IO rate has to be supported. You need to work out how many IOs per second are required then a suitable disk array can be configured. If your environment is Write intensive then you will say a 6 disk system configured as Raid 0+1. Here, if each disk is 2TB you will have about 6TB of usable space and each disk may be able to do 100 IOPS. Whether this is adequate or overkill depends on what you need. But what is not optional is some Raid arrangement - you have to be able to keep processing after a disk failure. Raid 5 is the cheapest but there is a heavy Write penalty and more risk that a Raid 1 (or 0+1) system.
Finally, a server. The example server above was way too small. An IBM System x3690 X5 has two sockets, 20 cores and 40 threads and four of them would give you 160 threads and you could lose one server and still process 120 threads. an IBM System x3850 X5 has 4 sockets 40 cores and 80 threads and three would allow you to lose a server and still handle the peak load. These are seriously large and expensive servers but then you seem to have a seriously large load.
Cheers
Keith
Topic: How to spec a Nettalk WebServer (Read 3958 times)