Если вы используете .NET классы для этой цели, вам не нужно вручную блокировать приращение, уменьшение и запрос счетчика производительности - инфраструктура сделает это за вас.
Если вам нужно использовать счетчики производительности в нативном коде, вы все равно должны использовать InterlockedIncrement () и друзей.
Я думаю, что асинхронное обновление счетчиков производительности не очень хорошая идея, но ваш пробег может отличаться. Это может считаться менее полезным, если данные о какой-то интересной ситуации поступают после факта. Во всех случаях я бы не давил на ThreadPool только для обновления счетчика производительности. Теперь, если вам все равно нужно выполнить работу, которая запускает счетчик в потоке, это, конечно, будет что-то другое.
Как правило, я не думаю, что обновление счетчика производительности действительно является узким местом, а скорее сбор данных, которые используются для обновления счетчика.
Например, счетчики производительности .NET GC Memory обновляются только тогда, когда GC действительно происходит, потому что отслеживание информации (в фоновом режиме) просто для обновления счетчиков каждый раз, когда что-то может быть слишком дорогим (извините, здесь нет ссылок, но есть несколько записей в блоге MS на эту тему).
Наконец, имейте в виду, что WCF уже предоставляет довольно большое количество счетчиков из коробки, которое может охватить все, что вы хотите уже сейчас.