Webstat performance when listing tabled predicates

Hi all, but probably mostly @jan. (Aside: It’s been a while Jan, I hope you are well!)

I recently had someone report a memory usage problem to me. I tried to use webstat, but ran into an interesting problem where webstat itself started to have performance problems :grinning_face: To be more precise, loading or refreshing the tabled predicates page began to timeout and return 500 errors.

I figured out how to increase the timeout to 1800 seconds via this. But it quickly hit that limit as well.

Do you have any ideas what might cause the predicate page to be so slow? I can provide instructions on how to reproduce this offline, but it requires a lot of ram (the machine I was using has 256 GiB ram).

Hi Eward,

Yes, all fine here :slight_smile: I guess the stats should be more or less linear in the number of tables. It’s too long ago for my memory to know how long this normally takes. If it makes a wild jump from what is normal there could be a bug.

If I have something I can reproduce, I can have a look. I’m afraid I only have 128Gb in this machine though :frowning:

I’ll put together a reproduction package for you. I think with 128 Gb you should be ok, as the slowness in webstat happened well before the program ran out of memory.

1 Like

Yes, it should be no problem. I just verified on my laptop with only 16 Gb :joy:

To reproduce:

  1. git clone -b webstat-repro https://github.com/sei-eschwartz/pharos
  2. cd pharos/share/prolog
  3. swipl
  4. ['demo.P'].
  5. ed.
  6. Let run for a minute or two. I didn’t time, but it was less than 5 minutes.
  7. Open/refresh the tabled predicates tab. It spent over 5 minutes, and then I stopped counting!

I can see that dethunk has many tables, but not so many that I think it would cause a problem for webstat…

Sounds doable. I’ll try to have a look in the coming days.