From what I can recall from when I was RE'ing the stats systems of various halo games is that they're able to make use of session IDs, that are generated at the start of match by either the XBL services or their servers (forget which exactly). If I recall, these session IDs are only 64 bits.

All a dedi in this case would have to do is request a session ID for the game to be hosted, and provide that same ID for all traffic. I'd figure HStats would be doing something like this already. You can easily reuse the game start/end datetimes to figure out if a session is active or closed. For heartbeats, you could just have a collection of dedi runtime state data (could do it purely in memory, not database'd) on the HStats server itself.

* When the server gets a heartbeat, it looks up the runtime data for that session, instead of performing a SQL query for every heartbeat.
* If a heartbeat fails to come in at the predicted time, then that runtime state could just be informed that it's now invalid (leaving it to perform invalidation measures, however severe that may be).
* When the game ends and that final heartbeat comes in the runtime state can be removed from the state dictionary and left to do its processing

I'd figure this would be less resource intensive since you're not relying on network resources for actual sessions (as you would with say TCP). You would also be dealing with a small subset of the stats DB using the runtime state (still using the session IDs of course), meaning fewer to zero trips to the DB itself (at least until it comes time to process the stats). It's entirely asynchronous. No session or runtime state is dependent on one another. Theoretically, no players should be in two matches at once so no player transactions/updates should happen at the same time. The bottleneck comes down to receiving and then pushing the HTTP requests payloads to the runtime states.

Of course if you're wanting to present partial results of a current session, some of this goes out the window as you now have to update the DB on some/all heartbeats instead of the final. However, you don't see any games providing the ability to see partial game stats for in-progress sessions, so why someone would want to go that route in a production environment (which can only go up in use) is beyond me.

PHP is able to run DLLs which export C symbols (you could do it in C++ just as long as the API was exposed as plain C) last I checked. So both a Linux and Windows server should be able to run a utility DLL for your more intensive processing that for whatever reason can't be efficiently done in PHP itself.