I am using Ignition 8 connected to Allen Bradley.
By default, The Default tag group is 1000ms refresh rate.
i have tried to reduce to 100ms but the response time is still very slow.
I have confirmed that the communication between HMI and PLC is fast enought (very low ping).
Any other solution or where i check the refresh rate status on Gateway?
What type of tags are you reading? If you're reading AOI parameters, you won't get much performance out of it.and if you're reading only UDT members but have any members in the UDTs not set to at least Read external access, you always won't get good performance.
Rockwell have deliberately shot themselves in the foot by not publicly releasing the documentation for efficient access to aoi parameters, however obviously their own software utilises methods to make comms to aoi parameters efficient, which is most likely why you're seeing the difference.
If you can't use UDTs in the plc and you're not using plantpax v5 (comms to v5 will always be terrible), then you can also use Phil's Automation Professionals' EtherNet/IP Communication Suite V2 to read aoi params efficiently, as he has reverse engineered the protocol.
Reading only UDT members, I've tested reading 8000 tags from an L82 @ 10ms. Make sure to increase the cip size as well up to 4000, depending on controller
By reducing your rate, you're only making it worse. Just left a site a couple weeks ago that tried to do the same thing and when I slowed it down things got much better. Check the device status in Ignition and you'll probably see it's overloaded.
Reading some of the Plantpax 4.0 AOI tags - UDT in Ignition. (less than 50 UDTs)
and the rest is Program Tag (60%)
I can see my Overload is above 283% and i dont know why my monitored item count is so high. This is very small PLC project (less than 500 tags) and some Plantpax AOI.
Now my whole ignition performance is very lag.
Lol, less than 50 AOIs and it's at almost 30k tags going to Ignition 
PP never ceases to amaze.
OK, seriously though, how many tags are defined in your UDTs for those aois? Is it all of the parameters defined in the PlantPAX AOIs? Or just a subset?
Did you change the cip connection size in the device settings?
Unfortunately to read aoi members efficiently, you will need to use Phil's driver. I suggest you trial it in the trial period and see the results. You will need to ensure that every Plc aoi member is set to at least Read external access (you can just create a device connection using Phil's driver with the same name as the old one, after renaming the old one; plc addressing is exactly the same). Note Phil's driver uses load factor where >100% is bad, whereas IA changed to using overload where > 0 is bad
Ps. The request count in that screenshot is 2251 which is utterly insane, and clearly indicates that you are reading AOI parameters and/or plc UDT members where every member in the UDT does not have its external access set to at least Read. This is absolutely critical to get decent performance
For reference, the request count should be less than 50ish for that many tags
Follow what @nminchin says but if you can't take an outage to download to the PLC then at least change your tag group for now to leased with like 30000ms rate and 1000ms leased rate. It won't fix the issue, but will significantly improve responsiveness for now until you can change ALL tags in the AOI to at least read only for external access. And definitely increase CIP connection size to 4000.
In comment #2, Nick deep-linked a topic that has become a meta-topic for Logix comms issues. You should read that whole topic, and the related topics that are cross-linked there.
I forgot to ask, what processor are you using?
Aside from reading the linked topic as suggested, I just want to state, that Ignitions standard driver is not going to be very successful being polled at this rate, if you truely need this type of response time, then you will need to either use a third party module caple of First Class comms, or B use specific buffering logic in the PLC to read multiple data points at once.
There are various topics on the forum about that particular thing.
Even a third party module capable of the speeds you're suggesting you need, won't overcome the limitations that Rockwell has bred into PlantPAX and AOI's in general.
*bred (unless you're saying the limitations are.... 
baked in)
I am, but I fixed it any way.
I beg to differ. My tests were reading ~7000 UDT members at 10ms rate with the standard logix driver 
not sure if you saw my linked post above with my test results. I posted the ACD and my tags in case anyone wanted to run it themselves with other hardware
I saw the post, how fast were those values changing in the PLC?
I'll get back to you on that one!
I don't know that that matters. All values are polled from the driver's standpoint, so if it's showing it's reading at that rate, it should be that rate. Whether tags are changing or not is irrelevant.
It may not, however, I would want to know that there was 1. Some load on the PLC aside from comms and other basic things, and 2. Some definative evidence that I am truly reading the value from the PLC.
Ignition's display of Actual Sampling Interval is (often) bogus. Some of your screenshots had Actual Sampling Interval faster than the Mean Response Time, which is utterly bogus, especially when the number of requests is greater than the concurrency.
Yeah, it's calculated using the mean from the histogram belonging to the timer measuring queue duration, which uses an exponentially decaying reservoir. It's a bit wishy washy except in steady state. It kind of flattens away spikes in response time.
But it is flat wrong when the overall poll time is dominated by response time, not queue dwell time. Like a 1ms poll interval that displays slightly more than 1ms as the actual sampling interval when the same block of stats shows a ~30ms response time. Just wrong.
My driver diagnostics include an actual sampling interval that is measured from start of batch submission to last item of the batch receiving a value. Queue dwell doesn't belong in the calculation.
Since I don't know the inner workings of your driver nor IA's driver, I'm just thinking of how I would expect statistics to be calculated.
Like I said. I don't know the inner workings of this, so maybe this is already being done and just called something else, or calcualted some other way.
It would be really cool to have some sort of "diagnostic" list/export of tags that can't be optimized/read in blocks for the Logix drivers and a reason why (if there's a known reason). Like...Not all tags in datatype are accessible....Atomic Tag....Polled tags of datatype do not exceed threshold for optimization. And maybe one that can tell what tags of datatypes are being read at 2 different rates that could be combined into the faster rate to reduce polls to the PLC.
Those things alone would help those unfamiliar with these optimization techniques find ways to optimize their structures, and maybe reduce the number of times this stuff comes up on the forums. (I understand though it's probably a big undertaking to do something like this though).
