Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Welcome to our site

Take a moment to join our board

Sign in to follow this  
Spuzzum

C# Server Application with Win32

Recommended Posts

I've been coding my server using C# and I did it with an user Interface only to show the server statistics and log in a friendly way. Of course the game logic and everything runs outside of the GUI Thread but, can the GUI make the server slower in any way? There's anything like GC or something in the UI that can make it slower in any way?

It's been doing fine with 30-40 players in a 1 Thread 2 GB RAM VPS, but I'm not sure if it will scale well in a production server environment.

Share this post


Link to post
Share on other sites
1 hour ago, Spuzzum said:

I've been coding my server using C# and I did it with an user Interface only to show the server statistics and log in a friendly way. Of course the game logic and everything runs outside of the GUI Thread but, can the GUI make the server slower in any way? There's anything like GC or something in the UI that can make it slower in any way?

It's been doing fine with 30-40 players in a 1 Thread 2 GB RAM VPS, but I'm not sure if it will scale well in a production server environment.

It really depends on how you implemented the GUI. If the window is being created using a single threaded apartment model, then your server could be under very serious performance constraints as it mashes all CLR threads into a single OS thread. You can easily check for this by calling Thread.CurrentThread.GetApartmentState on one of your server threads. Generally, having a GUI on a server executable (especially as the main thread) is bad practice, but if you're not looking for ways to squeeze performance out of every nook and cranny, then having a GUI under a multithreaded apartment model is probably fine for your use case.

  • Like 1

Share this post


Link to post
Share on other sites

IMO, if you're worried about performance you should separate the GUI from the server all together. Something like RPC to get server stats/details on a by-need-basis only. This way you're not utilizing resources for the GUI even when you're not even utilizing it. 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, W1cked said:

IMO, if you're worried about performance you should separate the GUI from the server all together. Something like RPC to get server stats/details on a by-need-basis only. This way you're not utilizing resources for the GUI even when you're not even utilizing it. 

I agree with you, but I think there're better ways to improve the performance of a server application. Appropriate data structures is one thing, like using a dictionary for key lookup rather than doing a search. Linq is a lovely addition to .NET, but usually encourages bad implementations from misuse. Algorithms are also very important, such as knowing your big-O and distributed big-O against a database. Database queries are also very costly in comparison to a cache lookup. So again, I agree with the GUI not being in a server executable, but at the same time I think there's a lot more that could be impacting performance more heavily.

  • Like 1

Share this post


Link to post
Share on other sites

Sometimes the Generator Thread get's congested due to the volume of monsters to generate when everyone has 2-3 accounts on auto-hunt on all maps xD and then it takes a few 'ms' to make what it have to do, then the server itself stucks for ~800-1500ms.

And since I'm running on a single-core VPS I don't know what to think, because I changed the server from Win32 to Console. It has almost the same structure of the old source, but this one has this problem.

Share this post


Link to post
Share on other sites
On 11/25/2019 at 11:19 PM, Spirited said:

I agree with you, but I think there're better ways to improve the performance of a server application. Appropriate data structures is one thing, like using a dictionary for key lookup rather than doing a search. Linq is a lovely addition to .NET, but usually encourages bad implementations from misuse. Algorithms are also very important, such as knowing your big-O and distributed big-O against a database. Database queries are also very costly in comparison to a cache lookup. So again, I agree with the GUI not being in a server executable, but at the same time I think there's a lot more that could be impacting performance more heavily.

What also really helps is indexing your data in your tables.

Also in code, try not to use things like ToList() or ToDictionary()

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Spuzzum said:

Sometimes the Generator Thread get's congested due to the volume of monsters to generate when everyone has 2-3 accounts on auto-hunt on all maps xD and then it takes a few 'ms' to make what it have to do, then the server itself stucks for ~800-1500ms.

And since I'm running on a single-core VPS I don't know what to think, because I changed the server from Win32 to Console. It has almost the same structure of the old source, but this one has this problem.

Well, if you'd like some feedback on your routines, let me know. You can always add me to a private GitLab repo, @Spirited. It's hard to squeeze out performance for a single core, one executable server. 

Share this post


Link to post
Share on other sites
18 hours ago, Spirited said:

Well, if you'd like some feedback on your routines, let me know. You can always add me to a private GitLab repo, @Spirited. It's hard to squeeze out performance for a single core, one executable server. 

Specially when I'm trying to run 15.000 monsters in the World with the AI active on all without interruptions even when the map is empty. I'm using an private Azure Repository, humm

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.