In graphics, you can measure "frames per second" on a target system, and tune your graphics complexity to hit specific goals.

Similarly, a sound mixer might measure "percent of CPU used," although sound is so cheap and CPUs so fast these days that it's unlikely to ever be a few percent of a single core, even with massive reverbs and other effects.

Networking is even less data than audio, so it's unlikely to ever take enough CPU power to show up on a profile.

Instead, you decide on a particular strategy, and your implementation either implements that strategy, or it doesn't.

Once it correcty implements the strategy (without unnecessary problems/delays/whatever) then that's as good as it gets.

It's still interesting to measure variuos properties (especially time between various points along the input / event / processing / forwarding chain) to compare against what your theoretical model says it should be, to look for bugs and areas of improvement.

There are parameters you can tune. For example, how many simulation steps do you gather together into a single network packet? How much de-jitter buffer do you use on the receiving end of a connection? Keeping a firm hand on these, and understanding the gameplay impact of changing them, is important, but it's usually more black and white than most other parts of the game. Either your messages make it to the server on time, or they don't.

@ApochPiQ: You are correct, of course, buggy network code can (like any buggy code) pop up on a profiler, and poor use of bandwidth can of course lead to an untimely death. Profiling your application's usage of all resources (CPU, RAM, disk, network, user attention, etc) is always useful and will always find surprising opportunities for improvement. Networking is not immune to that!

Metrics that are related to networking that application operators typically track over time, even after networking has been shown to be correctly implemented, will include things like:

- use of bandwidth (packet count and byte count per user connection)

- latency (physical level ping times, and application-level round-trip times)

- tolerance to packet loss (how much divergence happens when packets are lost)

These are generally very application specific, and thus measuring them is important to the application, but really hard to compare between applications. Is the impact of the packet loss metric for Gears of War comparable to the packet loss for Eve Online? Probably not :-)

There are of course also the low-level metrics used to judge your provider's quality; packet loss, connectivity, actual throughput, queue depths, etc.

These are usually well served by existing operational metrics, and will often just be scraped (through SNMP or whatever) from your edge routers.

A little late to the conversation but a metric in general is just a data point. How important it is to you depends on the context in which you look at it. That being said, much of your generic networking specific metrics from the server side perspective can come from outside of your application from existing network tools such as SNMP, ntop, snort and more. While the learning curve of these runs the gambit from small to zomg! they exist specifically for the reasons I believe you asked - though even more generic since they don't care if your application is a game or not. You can get packets per second, bandwidth utilization to/from specific clients, jitter, packet loss and so much more. I work at an ITSP and these tools are essential for us as we can quickly identify if a new application was introduced on our network or if an application or even specific client is acting up or having issues.

There are older tools like rrdtool with C and many other language bindings that you basically send key value pairs at timed intervals to for things you would like to keep track of and also offers a way to visualize that data. Things like grafana and influxdb have taken this concept to another level of scale being used by highly distributed web services today where network and database transaction metrics help them prioritize optimizations and user experience.

As for what metrics look like - they are generally just key value pairs you export at timed intervals and some other tool helps you visualize it in the manner appropriate to you. What is interesting to you? If your application can export metrics to a message/event queue and let something else do the imports to whatever tools you want, the tools you use can change independent of your application.