Measuring time from Ignition to the PLC is quite hard. The clocks are not synchronised, so you can’t work with timestamps.
You can measure the round-trip time (Ignition to PLC and back) by letting the PLC update a different tag and checking when that changes. The other way around works too.
But you can’t just divide it by two to get the send time. Due to the very different nature of the two involved devices, one way is likely to take longer than the other way.
The times also aren’t constant. OPC-UA works on top of TCP/IP, which is non-deterministic. Any router or switch on the way may choose when which packets are send. The aim is to send it as fast as possible, but on a congested network, this isn’t always possible. On top of that, the OPC-UA standard also allows the involved devices to delay updates. So the whole communication stack works on a “best effort” level.
The # of tag value changes is simply, the number of values that changed for the tags you are subscribed to (the tags that are displayed).
I don’t know what the tag throughput is. For me, it’s a very constant value (depends a bit on the project, but even then seems to always be between 3 and 4). So I guess it’s more related to project configuration…
The gatway ping is the time it takes for the client to send a packet to the gateway, and for the gateway to reply (so also a round-trip time). On a good local (wired) network, this shouldn’t go above 5. WiFi and WAN networks will increase that ping time.