Observability - Remote Tables - Caché memory usage

julianponce
Tera Contributor

Hello community!

So I'm working in a project where we are getting data from an external system and storing in a Remote Table , I'm then using that data to expose it on a form (catalog item). 


I'd like to know "how much memory" are we consuming from the system to store the temporary data on caché (remote tables). So that I know how many records I can expose without generating impact to other users.

Thanks in advance for any suggestion or heads up on this! 

1 ACCEPTED SOLUTION

Matthew_13
Mega Sage

Hello! That’s a great question, and it comes up quite often when working with Remote Tables.

In short, Remote Tables don’t actually store the external data in your instance the way a normal table would. They behave more like a live view into the external system. While ServiceNow may use some short-lived caching internally to improve performance, there isn’t a documented or user-visible way to measure that cache in terms of memory consumption, or to translate it into “X records equals Y amount of memory.”

Because of that, this is usually approached less as a memory-sizing exercise and more as a performance and impact consideration. The main things that can affect users are the response time of the remote call, the size of the data being returned, and how often those calls are executed (for example, when loading a catalog item or searching a reference field).

A few general best practices that help avoid issues:

  • Avoid exposing very large result sets directly on forms; encourage users to search or filter.

  • Apply tight filters so only the data that’s truly needed is returned.

  • Limit the number of records returned, if possible, on the integration side.

  • Test with realistic usage (multiple users accessing the catalog item) and watch transaction times and logs rather than focusing on cache size.

So while there isn’t a hard number you can plan around for cache memory, keeping queries small, filtered, and efficient is the best way to ensure you don’t impact other users.

 

@julianponce - Please mark Accepted Solution and Thumbs Up if you find Helpful!!

View solution in original post

2 REPLIES 2

Matthew_13
Mega Sage

Hello! That’s a great question, and it comes up quite often when working with Remote Tables.

In short, Remote Tables don’t actually store the external data in your instance the way a normal table would. They behave more like a live view into the external system. While ServiceNow may use some short-lived caching internally to improve performance, there isn’t a documented or user-visible way to measure that cache in terms of memory consumption, or to translate it into “X records equals Y amount of memory.”

Because of that, this is usually approached less as a memory-sizing exercise and more as a performance and impact consideration. The main things that can affect users are the response time of the remote call, the size of the data being returned, and how often those calls are executed (for example, when loading a catalog item or searching a reference field).

A few general best practices that help avoid issues:

  • Avoid exposing very large result sets directly on forms; encourage users to search or filter.

  • Apply tight filters so only the data that’s truly needed is returned.

  • Limit the number of records returned, if possible, on the integration side.

  • Test with realistic usage (multiple users accessing the catalog item) and watch transaction times and logs rather than focusing on cache size.

So while there isn’t a hard number you can plan around for cache memory, keeping queries small, filtered, and efficient is the best way to ensure you don’t impact other users.

 

@julianponce - Please mark Accepted Solution and Thumbs Up if you find Helpful!!

Alok Gupta5
Tera Guru

Hello @julianponce ,

 

As the cache memory we can not check in our instance and we know this is more about how can we handle data because in 1 go if you send Millions of record to Servicenow it might be slow down the system. So better we  have make a design in such a way through which our system will not impacted.

 

Regards,

Alok Gupta

Technical Architect