I need to know if there is a tool or a means of making a stress test in my game. My doubt is simple: The resources I need to keep an online player and through the calculation to find out which approximate number of players can achieve in the state where my game is. basically I want to know this to try to minimize this cost to much as possible.
| |
You also have to think to yourself how often things will actually be called in a real time situation and sort of budget how much time you can afford to spend on something. Optimization is more about knowing when something is an O(1) problem, an O(N) problem, or an O(N^2) problem, etc.
Usually I just tell people to look for loops. | |
Check your loops.
Precache everything you can. Send as much stuff client-sided as you can that makes sense being client-sided. Use the Dream Daemon Profiler and Memory Usage to check statistics. Host a testing event and get as many people as possible to check networking, or fake it and create a lot of /mobs and have them do exactly what players would do. Run that for 24 hours and come back to see the results. Check in periodically to see if there's been major CPU spikes and if so, why. | |
The profiler is your friend here. What you'll want to do is get some data from the profiler first, looking for procs that take up a lot of time--especially if they take a lot of time per call. (E.g., something that's called a million times but takes 1 second total is probably behaving really well.) Those are the places where you can probably find savings.
When you know which procs to look at, do as Ter suggested and try to cost them out in terms of their complexity. Do you have a loop within a loop? That's likely an O(N^2) situation--meaning if there's a formula that describes the number of operations, its biggest term would be N^2 multiplied by a constant. General rules of optimization to live by: - If all or part of a calculation can be done once outside a loop instead of inside, do it outside. - If a long loop depends on a var like list.len and you know that var won't change, assign it to a local var that can be read faster. - If a loop is frequently called, regardless of its length, consider seeing if you can do it backwards. Comparing the loop counter to a constant like 0 or 1 is faster than comparing to a var. - If you can inline something instead of having a soft-coded proc do it, sometimes that's faster because it avoids proc call overhead. #define can help you here. I'm forgetting a lot of others, but the gist is once you're looking at a routine, you want to eye it carefully and try to figure out if there are any subtle tweaks that could make it faster. If you identify any procs that you want to optimize, I'm sure we can offer some pointers if you post them here. | |
Things that you should stress test and optimize the most are the small things that are called often.