Long Load Times

I’m running into the same problem. I thought an upgrade may be in order, but that made no difference. I’m on the 1.10.9-standard. I have a widget on the front page that takes no less than 7 seconds to load (with 3 items in it). The month view calendar page is even worse. We have about 30-40 events each month. Nothing that I would consider excessive.

I’ve seen complaints all over the forums about this, but there doesn’t seem to be a consensus about what is causing it. Some are saying that it’s happening due to excessive spidering by the search engines. I’ve made some adjustments to eliminate that possibility but it hasn’t had any effect at all. Even if that was the case, it would be hit and miss. Spiders aren’t on the site 24 hours a day. The performance issues I’m seeing are consistent and constant. Other posts seemed to point to high numbers of events in the calendar being a culprit. Again.. I don’t think 30 or 40 events is excessive.

I watched TOP to see what my server was doing while clicking through the site and did notice it using a lot of resources. Sometimes it just hung and stopped “going anywhere”. I had to return to the homepage and come back into the calendar to get it moving again. Due to this… I can’t help thinking that there are some really inefficient AJAX calls going on. Lending to that thought is the fact that the AJAX spinner is spinning for 7 seconds while I’m waiting for the data to fill the widget. Same experience on the calendar page. Is this what you are seeing, perkypixel?

Found this thread while trying to troubleshoot the same problem. All pages of my WordPress site take an unusually long time to load when the all-in-one calendar plugin is active regardless of whether I’m on a page with a calendar included or not.

I think the problem is with the auto-generated css for the calendar. I’m noticing a ton of “Error in parsing value for…” entries in the Firebug console. Over 500 of them attributed to the ai1ec_render_css auto-generated css markup. I know it’s over 500 because I had to increase the log limit from 500 to 1000 just so firebug would not quit logging before it was finished loading the page. It takes several seconds for the browser to attempt to parse all that redundant, browser specific css markup. Do we really still need to cover webkit-, -moz-, -o-, and -ms- browser specific css definitions? Is there anyway to bypass this stuff or use something other than the auto-generated css markup for this calendar? I’d rather have a faster loading website.

Or maybe what I’m seeing is just a symptom rather than the cause of the problem.

Our plugin is quite memory and power hungry as of now ( 2.0 will hopefully solve that ). CSS generation shouldn’t be a worry though as we generate the css only once and then cache it on APC/File/Database (it depends on what’s available).
As of now the best solution for performance is installing either a system wide cache like varnish or a cache plugin.

We are having the same issue. We are experiencing such high load times that will, at times, crash the MySQL database. We moved our servers and added more processing power but it still will crash the site. It currently takes up 90% of the load time.

When will 2.0 be released?

I’m also running 1.10.9-standard and started experiences slow to never finishing loads. MySQL had a bunch of UPDATEs to option_name=’ai1ec_scheduler_hooks’. Which traced back to this:

all-in-one-event-calendar/constants.php:

-		define( 'AI1EC_N_CRON_FREQ',        'daily' );
+		define( 'AI1EC_N_CRON_FREQ',        '1d' );

Every page view, Ai1ec_Scheduling_Utility::reschedule compares $existing[‘freq’] (“1d” from database) and $freq (“daily” from AI1EC_N_CRON_FREQ), then replaces “daily” with “1d” and updates the db (and some more work). Repeat forever.

Paging nicola.peluchetti

@harris1 even if i do 1 update every request the overhead should be 0.0001 seconds this is not the problem i guess. Our issues are more related to PHP as we load the entire code base on every request and this hogs resources. Anyway version 1.10.9-Standard is the best version to use.
Please also read this article

https://support.time.ly/limiting-excessive-google-crawls/

Thanks Nicola, I updated robots.txt.

I know it seems silly. I probably should also mention our MySQL is using InnoDB tables on spinning disks on an overloaded machine due for replacement. An update still packs some punch.