How to measure the performance of delivering remote announcements

When working with remote objects through proxies, PharoLink allows local objects to register for remote events.

The current mechanism uses queues to pull and deliver announcements in bulk in a background process. GtRrAnnouncementQueueLocalListener Object subclass: #GtRrAnnouncementQueueLocalListener instanceVariableNames: 'announcer processLabel terminationCondition timeout isPolling proxy requestTermination poolingProcess' classVariableNames: '' package: 'RemoteRunner-AnnouncementQueue' provides more details.

Delivering large numbers of announcements can be slow if they contains a lot of data, or objects receiving those announcements do a lot of work. GtRrAnnouncementQueueEventsCollector GtBeaconEventsCollector subclass: #GtRrAnnouncementQueueEventsCollector instanceVariableNames: '' classVariableNames: '' package: 'RemoteRunner-Logging-Events' provides a way to monitor the delivery of remote announcements and measure performance.

The simplest way is to use the default instance of the collector.

GtRrAnnouncementQueueEventsCollector start.
  

GtRrAnnouncementQueueEventsCollector stop.
  

GtRrAnnouncementQueueEventsCollector reset.
  

GtRrAnnouncementQueueEventsCollector defaultInstance.
  

Aternatively we can create a new collector instance.

eventsCollector := GtRrAnnouncementQueueEventsCollector  new
  

eventsCollector start
  

eventsCollector stop
  

In case multiple instance of the collector are registered, the snippet below will stop them.

GtRrAnnouncementQueueEventsCollector allInstances do: #stop
  

The collector uses Beacon signals subclassing GtRrAnnouncementQueueSignal BeaconSignal subclass: #GtRrAnnouncementQueueSignal instanceVariableNames: 'queueId' classVariableNames: '' package: 'RemoteRunner-Logging-Signals' . It is also possible to listen for those events directly using beacon.

logger := MemoryLogger  startFor: GtRrAnnouncementQueueSignal.
  

logger start
  

loger stop