Large number of records in throttle table

[byjujohn]

Hi,

I have noticed a large number of records in the throttle table. All the records from the beginning of the project is still in this table. Is it the expected behaviour? I have noticed and expires config values for both activations and reminders. Should we not have some sort of sweep mechanism for the throttle table too?

There are more than 6 million records in this table. This is causing issues as it takes a long time to process the queries as you can imagine. Is there anything I can do to remove some of the old records safely from the table directly as a quick fix?

Thank you for your help.

[brunogaspar]

Hey @byjujohn

I think that adding such configuration makes sense.

@suwardany Can you leave your input here?

[byjujohn]

Thank you @brunogaspar.

So as an interim measure, am I okay to delete records which are created before the interval value for the corresponding type?

For example: delete from throttle where type = ? and created_at < ?

Here the type would be one from global, ip and user.
Also the date would be calculated using:

config('cartalyst.sentinel.throttling.global.interval')
config('cartalyst.sentinel.throttling.ip.interval')
config('cartalyst.sentinel.throttling.user.interval')

What you think?

Many thanks

[byjujohn]

Also persistences another one which potentially could be cleaned as well. I can see multiple records for the same user. I know this may be difficult as the same user may be logging in from different devices etc. But is there anything we can do on this?

Thanks

[suwardany]

Hello,

We could implement some means of sweeping these tables too, yea.

Needs some more thought, and would possibly be disabled by default, but i think the idea is good.

For persistences, this would likely mean that even people who choose to remember themselves would be logged out after the interval is over, so things like remember me for 30 days would replace the default behavior.

In the mean time, you should be able to delete the throttle records according to type and interval as you suggested without running into issues.

[byjujohn]

Thanks a lot for the feedback @suwardany 👍

For persistences if we can set the limit for how long the sessions should be remembered would be a great idea. We could try to keep the current behaviour, say for example if the value is 0, disable cleanup.

I managed to truncate the throttle table, as the site was keep going down. Also I made sure the site was not under attack, before truncating. The site is now really fast and didn't experience any issues. The MySQL error I was getting before was SQLSTATE[HY000] [1040] Too many connections.

Thanks a lot for your assistance.

[sabas]

I have a command in the admin panel to TRUNCATE directly the throttle table 😆
On persistences, shall we keep only the last valid persistence for each user?