Есть ряд проблем с этим.
Прежде всего, предпочтительным методом вызова службы WCF является модель для каждого вызова, например, ваш клиент вызовет метод обслуживания, который вызывает создание экземпляра класса обслуживания на сервере, соответствующий метод выполняется, а затем экземпляр службы снова удаляется. Таким образом, вы не можете реально контролировать клиентские соединения как таковые - они существуют только доли секунды, пока выполняется вызов.
Кроме того, на стороне сервера на самом деле не так много инфраструктуры для отслеживания вызовов в секунду и т. Д., Кроме счетчиков производительности. Новый серверный аддон, ранее известный как «Дублин» (в настоящее время называется «AppFabric»), должен принести немало улучшений в этой области (управляемость) - для получения дополнительной информации см. Эту статью MSDN .
Но даже сегодня вы можете представить себе класс обслуживания и следить за его созданием и уничтожением. У класса обслуживания также есть ссылка на ServiceHost
, которая создала его экземпляр через свойство OperationContext.Current.Host
, так что вы могли бы каким-то образом представить хосту сигнал о том, что был создан новый экземпляр класса обслуживания. Можно использовать только один хост-объект, чтобы он мог работать, но для этого требуется хорошо продуманный и хорошо протестированный подход с поддержкой многопоточности на ServiceHost (вы можете создать свой собственный ServiceHost для достижения чего-то подобного).
Это может быть шагом в направлении "мониторинга моего сервиса". Что касается мониторинга производительности - почему существующие десятки счетчиков производительности WCF не помогут вам или не предоставят вам необходимую информацию?