# Finding why an object is so big

**URL:** <https://forum.inductiveautomation.com/t/finding-why-an-object-is-so-big/97395>\
**Category:** Ignition\
**Tags:** scripting, perspective\
**Created:** [October 17, 2024, 3:16pm UTC](https://forum.inductiveautomation.com/t/finding-why-an-object-is-so-big/97395 "2024-10-17T15:16:06Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\
**Post date:** [October 17, 2024, 3:16pm UTC](https://forum.inductiveautomation.com/t/finding-why-an-object-is-so-big/97395/1 "2024-10-17T15:16:06Z")

</div>

I had an incident where some property in Perspective was triggering WebSocket failures in Designer for being too big. I was seeing errors like this in Designer logs:

```python
10:26:55.578 [Browser Thread: f73b9d02-a4fb-46e7-90f8-5c8d71526b74] INFO Perspective.SessionProps - store.Channel: Websocket connection closed. code=1009, wasClean=false, reason=Text message too large: (actual) 2,102,688 > (configured max text message size) 2,097,152, codeMeaning=Message Too Big, codeDescription=The endpoint is terminating the connection because a data frame was received that is too large.

```

I was having trouble figuring out which property, though. (We have a LOT of session.custom properties...)

With a tiny bit of tweaking, I was able to quickly change the ["object sanitizer" script](https://forum.inductiveautomation.com/t/function-to-convert-json-string-or-python-dict-into-objectwrapper/32861/16) into an "object sizer" script:

```python
from sys import getsizeof

def get_object_size(element):
    element_size = getsizeof(element)
    if hasattr(element, ' __iter__'):
        if hasattr(element, 'keys'):
            return element_size + sum(get_object_size(element[k]) for k in element.keys())
        else:
            return element_size + sum(get_object_size(x) for x in element)
    return element_size

```

It only reports the total sizes for the next layer down. So, you may have to drill-down a few times if you have heavily nested items.

I made a binding with a script transform like this:

```python
	suspect = self.custom
	result = {}
	for k in suspect.keys():
		result[k] = shared.utils.get_object_size(suspect[k])
	return result

```

I let that binding run once, figured out the worst top-level item, then tweaked the `suspect = ` line to point at that, and kept drilling down on the `suspect` until it was obvious which property had exploded in size.

I don't fully trust `getsizeof`, but I couldn't find a better Java library size function quickly and I didn't need exact results, just a hint of who was BIG. (Java is not my strong area...)

Mostly posting this as a helpful debug tool if someone else bumps into a similar issue.