Update:
My earlier post was mistaken!
I now see that when using the manual update I still get similar levels of memory usage.
I suspect this might be due to the plugin conflicting with another plugin.
I’ll look more into it now.
Update 2:
After re checking this with all plugins turned off (except for FeedWordPress and “TPC! Memory Usage”),
I am sad to report that the plugin memeory usage level is still high (for a website with ~110 feeds)
for example:
WordPress peak memory usage: 95.49 MB
Number of database queries: 35339
I hope the plugin author could extend the plugin with the ability to constrain the maximum number of feeds being checked.
Update 3:
I am changing this thread to resolved.
I now (embarrassingly) see that there is a site-wide definition for setting a “Time limit on updates”.
Assuming this works fine when it is in the middle of an update, then this solves my issue.
This leaves me only with the suggestion of adding a note about this in the “performance” section in the plugin.
Tal
Update 4:
Was wrong again – the problem persisted.
The “Time limit on updates” refers to the time spent for the fetching of each individual feed, not their total amount.
That means, that if we have 100 feeds, they can be limited to not be fetched if they take longer then 2 seconds to be fetched. But in total, the process could run for 200 seconds and result in the same amount of memory usage.
The problem stayed – any ideas anyone ?
Update 5:
O.k. , I stand corrected (Again),
I see here:
http://wordpress.org/extend/plugins/feedwordpress/changelog/
The clear defenition of “time limit on updates”:
LOAD BALANCING AND TIME LIMITING FEATURES FOR UPDATES: Some users have encountered issues due to running up against PHP execution time limits during the process of updating large syndicated feeds, or a very large set of syndicated feeds. FeedWordPress now has a feature that allows you to limit the total amount of time spent updating a feed, through the “Time limit on updates” setting under Syndication –> Options. By turning on this setting and adjusting the time limit to a low enough figure to avoid your PHP installation’s time-out setting. (PHP execution time limits are usually in the vicinity of 30 seconds, so an update time limit of 25 seconds or so should provide plenty of time for updates while allowing a cushion of time for other, non-update-related functions to do their work.)
If feed updates are interrupted by the time limit, FeedWordPress uses some simple load balancing features to make sure that updates to other feeds will not be blocked by the time-hogging feed, and will also make sure that when the interrupted update is resumed, FeedWordPress will skip ahead to resume processing items at the point at which it was interrupted last time, so that posts further down in the feed will eventually get processed, and not get blocked by the amount of time it takes to process the items higher up in the feed.
What I don’t get is that I just used this to update something like 5 feeds (for less then 15 sec), and I got the following memory update:
WordPress peak memory usage: 69.31 MB
Number of database queries: 4429
So even that I used such a low number, still, I get a report of high memory usage.
Now I am completely out of ideas of what to do … 🙁
I am not sure if the problem I am having is related but I had to roll back to an older version. My server cannot handle the memory that feedwordpress is eating.
14:22:27 up 3:07, 1 user, load average: 10.41, 7.40, 4.22
this is what my server is after feedwordpress w/ manual cron is enabled.
Whereas this is where it is average 14:54:22 up 3:39, 1 user, load average: 0.09, 1.70, 2.60
I have 900+ syndicated links.
Let me know if you find something out.
I ended up lowering my “number of seconds” to “3”.
After numbers like 15 and 8 where causing the memory usage to go beyond 60MB.
I hope future version might prove to be more light on memory. Or that with some caching server side this might be mitigated.
Update 6:
I lowered the bar to 1 sec limit, and there still seems to be a memory leakage.
I turned on the debugging mode and found out a bug that I reported in the linked thread, but I am not sure if that is the cause…
