MAX CPU Usage

Hi @shanafourde
Thanks – I tried adding the lines to robots.txt file. It does help a little but unfortunately not much. We used to use wp-super-cache with it but by activating this, it went way over the allowed resource usage. I deactivated it and have installed Quick Cache and this helped and our site is currently back and running again, but then only marginally. The CPU usage is still 75-100% most of the time and any additional overload would certainly kill the site.

I just saw @nicola.peluchetti’s update above – thanks. In fact, before finding this thread, this is the first thing I tried and tested but it hardly helped. My site only has now events on and after 1st May.

@nicola.peluchetti

Completely de-listing your entire site from Google, MSN and Bing by blocking access to their spiders – because of bugs with the event calendar? No, thanks!

Dear reader: please do not use the code above unless you want your site to simply disappear from all major search engines.

-1

Thanks for the updates, Nicola. After three days of having the robots.txt changes in place the issue still occurs (but I’ve noticed it takes longer to occur). Our sites that use the events plugin do have a large number of events and we do not delete old ones (but we’ll try and see what it does).

And I’m a little wary of blocking those crawling bots since it would have a negative effect on our search rankings for the respective sites. https://support.google.com/webmasters/bin/answer.py?hl=en&answer=2387297 explains what happens when you block Googlebot.

@mjhale Well said and much more diplomatically.

The problem happens whenever pages are hit, whether that’s by a spider or a human.

By blocking spiders, you are essentially decreasing traffic your site, which is why it seems to make things better.

However, whenever people hit the problem pages, the plugin still runs out of memory rendering those pages.

Focusing on bots, then, is somewhat of a red-herring – though there is a separate, duplicate content issue with allowing all events to be spidered.

We need to be focusing at the causes of the memory issues. The fact all events are loaded on some pages is a point in the right direction.

Can anyone pinpoint what release changes to the plugin started causing the issues? Maybe looking at what changed could help, or even downgrading to the last known good version?

Ok, the patch to have consistent url is the following one.

in file class-ai1ec-href-helper.php ( found in lib/router folder ) change lines from 13 to 25 so that they lok like this

private $used_paramaters = array(
		'action',
		'page_offset',
		'month_offset',
		'oneday_offset',
		'week_offset',
		'time_limit',
		'exact_date',
		'cat_ids',
		'auth_ids',
		'post_ids',
		'tag_ids',
	);

let me know if this stop the crawling.

@valpreston
we are working on the issue.
Above you find the patch for the bot crawling which you should associate to the robots.txt file.
The memory issue is more complex, we are working on that, but it shouldn’t affect the frontend.
I work for time.ly

@nicola.peluchetti
Awesome! I’ll have my developer look at the patch, and will watch for updates. We’ve had to upgrade our services with HostGator 3x in the last month, so I’m hoping it’s resolved soon, so we don’t have to keep paying for more resources:) I love the calendar, and prior to the last couple of upgrades, never had issues.

@ntemple
how much memory is the plugin using?What’s your memory limit?
If you have lots of events month view can be memory heavy because there are a lot of events on screen.