Okay, I make that 12 pollers at 300mS and about the same number at 500mS periods.
Everything is going through one IP/port (I guess this is a TCP-serial gateway?) so they have to be done one at a time.
That means you’ll have to complete about 18 polls in the space of 300ms, that would be about 17mS allowed per poll.
We don’t know how long a real poll-query turn around takes in your case, but 17mS is not going to happen. (My estimate here is about 85mS per poll)
So you will have a queue built up for access to your TCP gateway, and the binding will process poll requests as fast as it can.
“Duplicate” poll requests will be discarded, so at least the queue will not grow forever. But the queue is going to be as long as how many pollers you have.
When you make a write request, it will go on the back of the queue and in this situation will have to wait for 24 read polls to finish before actually getting to write to modbus.
24 polls x 85mS estimate = 2 seconds
Sound right?
Counter intuitively, to make it go faster you must poll slower, so as to avoid building a queue.
For a start, do you need to poll temperatures and lux at half-second intervals? Won’t every 5 minutes do?
Try backing the other pollers off from 300 to 800mS, see if that helps.
There are also other things you can usefully do to reduce host system load, every millisecond counts when you are trying to get this level of performance.