tforums

On 4/23/2024 at 9:04 AM, Jim M said:

We no longer cache full pages/responses. This was removed some time ago in effort to move customers more towards better solutions that wouldn't utilize so much server resources, e.g. CDN caching. We pass a cache header but it won't cache unless you have a CDN (or similar) servicing your community.

Sorry. I have not kept up with these changes because everything has been running so well until recently. You are right, a CDN is a better option for all the long term unknowns I am worried about.

On 4/22/2024 at 2:32 AM, KT Walrus said:

Sorry. I didn’t understand your issue. Maybe putting Cloudflare between the bot traffic and your server would help? That is, if you don’t mind blocking most bots from scrapping your site. 

Or maybe you could rate limit these bots with Cloudflare. 

Thanks. Like you said, the ideal solution is to maintain the HEAD option. IPB already caches a lot of things, so it should be possible to at least cache the header for the /discovery/ pages that are being hit constantly to check for updates.

This is only going to get worse as AI crawlers are deployed. Forums communities are being targeted for their embedded knowledge. Even if your site isn't getting hit a lot, I am sure it is adding a some load to the server. The IPB cloud service is likely burning a lot of CPU because of this. Do us all a favor please! 😄

7 minutes ago, KT Walrus said:

Isn’t this the way the web works? 

HEAD requests are an optimization so no need to refetch the page/file if it hasn’t changed. 

You wouldn’t want Google or some other search engine re-downloading something that hasn’t changed. This would waste tremendous amounts of bandwidth. 

Yes, I said that. Which is why I am trying to see if IPB can cache HEAD requests instead of hitting the DB every time.

Just now, Jim M said:

Do you have an example of the request? This could be the form of an attack, if there are many requests at the same time, which would need to be mitigated at the server or network level for optimal results as the software would just cause more consumption of resources.

FWIW, I don't think this is an attack so much as we are a very old, large, and popular community.

Yes see above. I could send you logs all day. Probably not something I should post here. LMK where to send them if you want to take a look.

... I cannot add to the post for some reason. But I am seeing some very abusive activity from Facebook and other scrapers where they slam a site with 10 requests from 10 different IPs. This appears to be a shortcut for them doing replication. Its much faster and easier to hit us 10 times than read once, and then sync their backend.

In the age of AI and Social Media, there are more bots than ever. I recently noticed we are giving up 70% of our server load to HEAD requests. This appears to be fueling a constant load on the database even when there is very little activity from members. If you are seeing a kind of pumping activity of load rise and fall, it is probably from this.

I have blocked HEAD requests to mitigate this activity because it is being done by dynamic IP sources without user agents and or ignoring robots.txt. However, this is not ideal as HEAD should be saving load from GET requests. Seems to me the IPB system could somehow mitigate this or is everything, even the headers, coming from the system DB?

IMO, IPB really needs to focus some tools on how to deal with bots and scraping. The AI boom is literally inciting others to machine-learn our community activity for who knows what uses. This is not only hurting our sever performance, it is abusing the community and members in ways we cannot forsee.

IDK what happened, but it is working now. *knock on wood*

I see the problem. The applications/cms files are not included in the current version. I don't see how / where to download those separately. Did something change?

1 hour ago, teraßyte said:

Looks like some of your files are not up-to-date. Download the suite package file from your client area and re-upload all the files to your server (be sure to overwrite the old files).

Thanks. Just tired that. Still getting the same error.

Thanks, I went ahead and activated display errors in the conf, and see this showing up:

Quote

Fatal error: Declaration of IPS\cms\_Categories::roots($permissionCheck = 'view', $member = null, $where = []) must be compatible with IPS\Node\_Model::roots($permissionCheck = 'view', $member = null, $where = [], $limit = null) in /site-name-removed/applications/cms/sources/Categories/Categories.php on line 263

Just now, Jim M said:

You would want to contact your hosting provider or server administrator to ensure that you are properly logging errors.

I am the admin and we are. The Locked Task: clubrebuild error is not related?

Thanks, but there are no errors showing up for the clubs in the Admin or Httpd server logs.

We are trying to remove the Classifieds 2.1.1 Application that is disabled since the Marketplace shut down. Unfortunately, the Uninstall option goes to a blank page and nothing is removed. Is there a process to remove Apps manually?

I am seeing this Alert. Everything else is running fine. Running manually tells me it is already running already and cannot be run again until the lock is removed.

Quote

Locked Task: clubrebuild

One of the routine maintenance tasks which run in the background has failed several times, which may indicate a configuration issue.

The separate Clubs pages are all blank now since the last update. 

Caches have been cleared and no errors showing in admin console.

Is there a fix for this?

On 1/24/2023 at 8:09 PM, Michael.J said:

Do you have any other blocks or changes to the Portal? I assume it's just the main latest topic blocks that is causing the issue?

Just a couple of side block with HTML. Yes, it is pulling the latest topics as a feed.

On 1/18/2023 at 12:23 PM, tforums said:

Having CPU load issues when Portal is made the default homepage after latest IPB upgrade. Please see the topic here.

https://invisioncommunity.com/forums/topic/471698-database-process-running-constantly-overloading-cpu/#comment-2923362

I have tried re-installing the Portal 1.8.1, but the problem is still there.

I can confirm this issue on two other installs. The SQL query needs to be optimized, please, so we can restore Portal to our homepages. Thanks!

2 hours ago, Mark H said:

OK, that PM error is something we're aware of and will be patching very soon.

Thanks, I found the support forum and posted there.

Having CPU load issues when Portal is made the default homepage after latest IPB upgrade. Please see the topic here.

https://invisioncommunity.com/forums/topic/471698-database-process-running-constantly-overloading-cpu/#comment-2923362

I have tried re-installing the Portal 1.8.1, but the problem is still there.

9 minutes ago, Mark H said:

In that case, we'd suggest you contact the author of that 3rd-party app for assistance in diagnosing this issue.

I am trying to, but any PM to the developer @Michael.J shows a forums error:

Quote

Sorry, there is a problem

Something went wrong. Please try again.

---

UPDATE - The process list hanging / CPU load issue seems to be tied to the Portal app being set as the forum homepage. When I set the home page to the IPB System, there are no "Sending data /  Creating sort index" tasks and CPU load goes back to normal. I have confirmed the load issue can be reproduced by switching Portal back to the default forum homepage.

I have disabled the Portal for Guests, and that seems to have cooled things off, but my guess is there's still something not right. What's odd is we've had this app installed at the homepage for years without issues until the last update.

SORRY! I spoke too soon. Seeing the hanging processes again in the DB after some time. Disabling Portal App stops them, so I am back on trying to debug this install.

UPDATE - It must have been a cached configuration issue. After updating the settings, it appears to be working without adding any load.

1 hour ago, Jim M said:

This is a partial query it appears. Is that the full log?

 

That would likely indicate that there is an error in acustom or third party application/plugin/theme. You would want to disable those and then switch an unmodified theme to test.

Thanks! It turns out to be the Portal 1.8.1 app causing the problem. This is odd because it is marked as 4.7.x compatible and works fine in our other installs.

Is there a Bug in the system? I see a lot of these errors in the system logs: