New web server
Because we are expecting a lot of visitors after the c't magazine is published, and because our old web server was kind of slow, we decided to pay more money but get a better server.
As with the old one, this server is in France, and is managed by our host.
We have 100mbps (no traffic shaping), fast CPU, and 1GB of RAM.
Transfering the forum was a pain, because we also wanted to update from IPB 2.1.7 to IPB 2.3.4 Long story short, it didn't work very well, so I had to contact the IPB support (we pay $30 a year for it). They were very fast and professional, as always, and fixed our problems. The only problem left is that our custom skin is not entirely compatible with this new forum version, so Roja is working at fixing it.
The end result is very encouraging, this server is significantly faster than the old one. Now I am confident enough that the website should handle whatever c't will throw at us.
As for the game server, we did a stress test where we had about 1.1K connections, and CPU was at 35%. Based on this information, I would expect to be able to handle around 2500 players at the same time. There are a few more optimizations that I can make, such as multithreading some time expensive routines, which will allow us to accomodate even more players, maybe 3K or so. But before that, I need to profile the server again and see which parts take most of the CPU time.
The client is almost done for the update, arrows and shaders work fine, we just need to do some more testing and we can have the update in 2 or 3 weeks.
As with the old one, this server is in France, and is managed by our host.
We have 100mbps (no traffic shaping), fast CPU, and 1GB of RAM.
Transfering the forum was a pain, because we also wanted to update from IPB 2.1.7 to IPB 2.3.4 Long story short, it didn't work very well, so I had to contact the IPB support (we pay $30 a year for it). They were very fast and professional, as always, and fixed our problems. The only problem left is that our custom skin is not entirely compatible with this new forum version, so Roja is working at fixing it.
The end result is very encouraging, this server is significantly faster than the old one. Now I am confident enough that the website should handle whatever c't will throw at us.
As for the game server, we did a stress test where we had about 1.1K connections, and CPU was at 35%. Based on this information, I would expect to be able to handle around 2500 players at the same time. There are a few more optimizations that I can make, such as multithreading some time expensive routines, which will allow us to accomodate even more players, maybe 3K or so. But before that, I need to profile the server again and see which parts take most of the CPU time.
The client is almost done for the update, arrows and shaders work fine, we just need to do some more testing and we can have the update in 2 or 3 weeks.
posted by Radu at 2:56 AM
4 Comments:
Random word of advice that you probably know already, but: For multithreading, make sure you multithread everything that deals with the hard disk, especially if you use the hard disk to look up things like character entries in a database. That kind of stuff gets really expensive, really fast.
Acutually, multithreading disk I/O is a very bad idea, unless if you use multiple disks (so each thread deals with one physical disk).
The reason for this is that if you access files from the same disk in multiple threads, the disk heads will have to move a lot between files, and you will get a decreased performance.
It is unclear what vpellen meant, but I think the idea was to separate disk I/O from other processing/networking, so you don't have just to wait for disks and waste time. However, if EL server spends relatively low time on disk operations, this "optimization" can be only a waste of programmers' time.
Btw, I saw on the forums that CT magazine was out, did you notice a significant increase of players?
The problem is that when you do an I/O operation, you usually do it because you want the data at that time, so you will need to wait for that data anyway. Of course, you could do other things while waiting for the data, such as calculating a path or something, but usually most of the I/O goes with the networking, not disk I/O, and that is already threaded.
Post a Comment
<< Home