Please, please, please fix this site.

[Kyle1886]

By preventing any "guests" you also prevent "lurkers", persons that want to scan the site, contents, etc. as so many of us did prior to joining. There is one site I used to visit that said if you "forget your password" set up a new one. Then the only way to get a new password is to put in your old password first. Brilliant!

Yes, this site requires that too, I just looked.

Kyle

[Librarian]

I have been able to get on 3 days in a row. That's a change.

[chrisw]

I have been able to get on 3 days in a row. That's a change.

Do you have mod powers available to you?

[BAJ475]

I have been able to get on 3 days in a row. That's a change.

K did post a few days ago that he was upgrading the server because the previous server turned out to be a disaster.

[TrappedinCalifornia]

K did post a few days ago that he was upgrading the server because the previous server turned out to be a disaster.

It was a little more 'involved' than that. Kestryll posted this afternoon...

Let's not get ahead of ourselves. I was finally able to hire a DB engineer to look at our database and he found several things going on and looks to have fixed them.
However we still have an issue that is coming out of the software. This is from the DB guy:
"The table cacheevent is growing too quickly and too large. vBulletin keeps continuously high-concurrency writing into this table, which is causing deadlocks frequently.
I cleaned the table today, but it grows back to millions of rows in a few hours."

vBulletin's initial answer seems to be 'You need to pay for an upgraded license.' I'm seriously kicking myself for choosing to update vB from where we used to be to this instead of switching to SMF or Xenforo.

We're doing better and moving forward but not where I want us to be yet.

I'll have to assume Librarian is aware of that post given his own post...

Re the cacheevent table ...

In vBulletin (especially v4/v5/v6), the cacheevent table is part of the built-in database caching system.
Purpose
It stores cache invalidation events — basically "tags" or markers that tell the system when cached data needs to be refreshed or cleared.
• vBulletin caches a lot of frequently used data (forum nodes, user info, settings, templates, etc.) in the cache table to improve performance.
• The cacheevent table tracks events (like "this node was updated" or "a post was added") that should trigger cache clearing for related items.
• This is an event-driven invalidation mechanism so the software doesn't serve stale data after changes.

How It Works (Simplified)
• When something changes (e.g., a thread is updated), vBulletin inserts a record into cacheevent.
• On subsequent page loads, the system checks cacheevent to see if any cached items are outdated → if so, it rebuilds/clears them from the cache table.

Common Issues
• This table (along with cache) can grow very large on busy forums → leading to slow queries, table locks, or crashes.
• Admins often TRUNCATE (empty) both cache and cacheevent tables during maintenance, server moves, or performance tuning. It's generally safe to do (the system will repopulate them as needed).

You can safely clear it via AdminCP → Maintenance → Clear Cache ...

ETA VB does not like something in X formatting - the quoted stuff is from Grok.