# Will there be a speed issue if we use 40K of tags to logged the data? **URL:** \ **Category:** General Discussion\ **Created:** [September 11, 2018, 8:33am UTC](https://forum.inductiveautomation.com/t/will-there-be-a-speed-issue-if-we-use-40k-of-tags-to-logged-the-data/19619 "2018-09-11T08:33:05Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![KYAW](https://avatars.discourse-cdn.com/v4/letter/k/54ee81/32.png) [@KYAW](https://forum.inductiveautomation.com/u/KYAW)\ **Post date:** [September 11, 2018, 8:33am UTC](https://forum.inductiveautomation.com/t/will-there-be-a-speed-issue-if-we-use-40k-of-tags-to-logged-the-data/19619/1 "2018-09-11T08:33:05Z")
Will there be a speed issue if we use 40K of tags with visualization or data logged? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 11, 2018, 12:47pm UTC](https://forum.inductiveautomation.com/t/will-there-be-a-speed-issue-if-we-use-40k-of-tags-to-logged-the-data/19619/2 "2018-09-11T12:47:11Z")
Recording 40k tags would be fairly heavy DB load at 1-second intervals with a modest load on Ignition itself, with decent hardware. Not much load at 1-minute intervals. Crushing load at 0.1-second intervals. If you are trying to visualize a span of 100,000 samples on a realtime trend, both DB and Ignition will be stressed. Yes, it’s a vague answer. We’d (I’d) need more detail on your requirements for more specific recommendations. ---
**Author:** ![Brian\_F](https://avatars.discourse-cdn.com/v4/letter/b/c37758/32.png) [@Brian\_F](https://forum.inductiveautomation.com/u/Brian_F)\ **Post date:** [September 11, 2018, 5:07pm UTC](https://forum.inductiveautomation.com/t/will-there-be-a-speed-issue-if-we-use-40k-of-tags-to-logged-the-data/19619/3 "2018-09-11T17:07:08Z")
I have a similar need to extract a lot of data to a database. Assume an interval of 1 minute. No need to visualize the data, just extract 16 arrays of length 3000 from a ControlLogix PLC and save to SQL Server DB. Could I ease the database load by packing each array to a byte string and saving to DB as a blob? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 11, 2018, 5:14pm UTC](https://forum.inductiveautomation.com/t/will-there-be-a-speed-issue-if-we-use-40k-of-tags-to-logged-the-data/19619/4 "2018-09-11T17:14:57Z")
> [@Brian\_F](#): > > just extract 16 arrays of length 3000 from a ControlLogix PLC Somewhat unrelated to your question, but perhaps a warning: an array of that length can't be read atomically. I'm not sure what would happen if while the driver was reading the array the PLC scanned and changed the data. You may end up with "corrupted" data unless the PLC sets the whole array aside in a buffer upon receiving the first request and serves the subsequent requests out of that buffer. @pturmel any thoughts? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 11, 2018, 6:05pm UTC](https://forum.inductiveautomation.com/t/will-there-be-a-speed-issue-if-we-use-40k-of-tags-to-logged-the-data/19619/5 "2018-09-11T18:05:37Z")
> [@Kevin.Herron](#): > > You may end up with "corrupted" data unless the PLC sets the whole array aside in a buffer upon receiving the first request and serves the subsequent requests out of that buffer. @pturmel any thoughts? If the data must be read in toto from the array, it is not safe for the PLC to change the data while Ignition (or any other class 3 consumer) is reading. If I recall correctly, base datatypes (INTs, DINTs, REALs), however nested in arrays or UDTs, will not be split in a fragmented tag read, though the data access specification doesn't actually mandate that. I wouldn't trust it. Any time I send structured data (in either direction), I use a pair of notification/acknowledgement integers. For each transfer, the sender fills in the structure, then increments its notification integer (rolling over). The receiver monitors the notification integer for changes. Upon change, it reads/processes the structure and then copies the notification value to the acknowledgement. The sender is forbidden to write into its structure while the notification and acknowledgement values differ. When Ignition is the receiver, I use a gateway tag change event script subscribed to the notification value (not a tag event) and `system.opc.read*` to grab the structure contents after the trigger, then `system.tag.write` for the acknowledgement. Using subscriptions for the structure content is not safe. This approach is not necessary if the array/structure is comprised of independent values updated asynchronously. ---
**Author:** ![KYAW](https://avatars.discourse-cdn.com/v4/letter/k/54ee81/32.png) [@KYAW](https://forum.inductiveautomation.com/u/KYAW)\ **Post date:** [September 12, 2018, 12:54am UTC](https://forum.inductiveautomation.com/t/will-there-be-a-speed-issue-if-we-use-40k-of-tags-to-logged-the-data/19619/6 "2018-09-12T00:54:19Z")
Actually we are planning to use OPC server from HMI with 300 machines. 1 Machine will have 50 data(analogue) to logged. What kind of scan rate will be recommended?