The site performance dramatically drops after the plugin is active.
This is true even after setting it to stop running feed checks automatically, apparently it just keep on doing a lot of external requests and even the front-end suffers this.
Anyone else having the same trouble?
Posted 7 months ago #
I am having similar issues.
Posted 7 months ago #
Please let me know if you find a solution. For me it seems that when the plugin is active and I have a lot of updating content it just does not want to stop making http requests to my server. Taking about 30 seconds to load my website.
Posted 7 months ago #
To me, the plugin still works, it still syndicates, with a lot of frequent duplicates. However I've noticed that for about a year, the site has been excruciatingly slow. Just this morning, it took 5mn to even start to load the front page. Often doing anything like deleting a duplicate in the dashboard takes so long, the request times out and takes me to an error page.
A year ago is also the last time the plugin was updated. I think it's not maintained anymore.
That is right, seems like it was discontinued. Too bad it's the only one that does this kind of thing.
Posted 6 months ago #
Hi, I have the same problem. I have a VPS and FeedWorpress ofter use all the memory and cause the server overload and down of the site. I have about 300 feed sources and I'm urgently looking for a solution.
I'm not a technician, but it seems the processes run all at the same time. If so...what if doing a addon or small modify on the code to start one feed update only after the previous process is ended?
I asked Charles (the developer for plugin) if there is a solution. No reply till now.
I have searched all over the web for a FWP add-ons or other solutions. nothing...
I haven't tried the Setting performance > Guid index yet because I haven't understand this option at all and I don't want to create problems on my db. What does it do exactly? which conseguences it has? is it a reversible process?
Posted 5 months ago #
+1
Posted 5 months ago #
You need more RAM. I have found that 2GB of RAM seems to do the trick for my on my VPS hosted by Linode.
That's a huge amount for a website, with having the plugin deactivated 128mb is more than enough.
Posted 5 months ago #
our site is hosted on probably the best WP host in the business (wp engine) so server performance is not the issue.
Posted 5 months ago #
I should also mention that I have 1000+ feeds syndicated. I think the issue is in the method by which Apache/PHP are using the RAM during the RSS query process. I found that I was running out of RAM and going to SWAP, which caused the server to use a lot of HDD I/O. One of the methods I used to reduce the amount of RAM used was to reduce MaxClients in my Apache config to 18. Here are the settings I use:
#
<IfModule prefork.c>
StartServers 1
MinSpareServers 3
MaxSpareServers 6
ServerLimit 24
MaxClients 18
MaxRequestsPerChild 3000
</IfModule>
#
Posted 5 months ago #
I have upgraded to a VPS with 2GB of RAM and now it's ok.
I have a problem with feed updates. I have set a cron to run http://www.mysite.com?update_feedwordpress=1 twice a day and it works, but I see not all feeds are updated: many of them are 'ready and waiting since 12,14,20, etc days)
These are my settings:
Default for all feeds: "Cronjob or manual updates" and each single feed is set as "update only when pinged" (I also tried to set 'on schedule').
I would like to avoid "automatically updates after/before page load" because it do it too much often causing unuseful overloads.
Does your FWP regularly check and updates all feeds?
Is there something wrong on my settings?
I just switched to another plugin:
http://wordpress.org/extend/plugins/wp-rss-multi-importer/
It's working great so far.
Posted 5 months ago #
@fedeuni,
I'm sorry to hear you're running into this problem. A couple of brief suggestions that I hope might help.
1. Take settings off "update only when pinged." You should immediately switch any feeds that are marked as "update only when pinged" *back* to "update on schedule." "Update only when pinged" is a bad label for the setting, but essentially it means that the feed will *only* be updated by requests that specifically say to update that one feed, and reference it by URL. (The part about "pinged" comes from the fact that one way this could happen in the past was to receive an XML-RPC update ping, if you had convinced the owner of the blog to add your aggregator.) Anyway, *if "Next update" is set to "only when pinged" that will never be checked for updates during the normal FWP update cron job*. After you have ensured that all feeds are put back to "update on schedule," you should give it a few hours for the update schedule to get caught up on feeds that it may have been missing.
2. Use a (much) more frequent interval for the cron job. Secondly, if you are only running the update cron job twice a day, this is almost certainly far too long of an interval for feeds to be updated in a timely fashion. (The number of feeds you would have to cover in any one of these twice-daily update sessions would be enough that it the HTTP latency alone will almost certainly cause server timeouts.) I would recommend running the update cron job about once every 10-15 minutes (!). (A FWP cron job does not mean that all the feeds are being updated on the cron schedule; it means that you are *checking in* on that schedule with FWP to see *whether* there are any feeds ready for an update. It should be safe to run this on a frequent interval because when there aren't any feeds scheduled for an update, the request will quit without doing anything further. And the scheduling mechanism is set up to try to stagger updates so that only a few feeds are being checked for updates in any given check-in.) If you've tried a frequent-interval update like this before, and it caused you problems that led you to institute the much less frequent checkins, let me know; I can try and help with the problem you were seeing before.
3. Finally, if you are having trouble figuring out what's going on with your update procedures, in general, it would be a good idea to check out the Updates section under Syndication > Diagnostics. This has a number of settings you can use so that you will be e-mailed logs of (for example) which feeds are being checked for updates and when, whether any feeds are experiencing update errors, etc.
I hope this helps.
Posted 5 months ago #
@radgeek
thank you !
clear, full and professional reply!
I will try to apply your suggestions asap!
I have about 300 feed sources. What's your experience with FWP? do you manage more feed sources? got any problem?
You seems to be an expert, so I try to ask you also another open point about performance:
I haven't tried the Setting performance > Guid index yet because I haven't understand this option at all and I don't want to create problems on my db. What does it do exactly? which conseguences it has? is it a reversible process?
Posted 5 months ago #
Hi there,
Thanks for the kind words. As far as my experience goes, I am actually the author of the FeedWordPress plugin (I also use it daily on about a half dozen personal projects).
I do not personally run any sites with as many as 300 sources, although I've consulted with some users who do run sites that large. In general it is possible to run FWP with this many sources, but, especially if they are very active, it does take some careful fine-tuning, especially around the update scheduling process.
I would recommend turning on the Guid Index setting that you found in the Performance section. The setting is fully reversible if for any reason you need to remove it. (When you click the button to create the index, it is then replaced by a button in the same place that allows you to remove the index. If need be, the index can also be removed through a single simply MySQL command issued directly to your database server.)
What the setting does is to create a MySQL index on the guid column in the wp_posts table. Essentially, this means that when WordPress sends a request to your database to search for post records that match the guid (a unique identifier URI which is assigned to every post at the time it is created, and which never changes even if you change all of the post content), these searches will be performed more quickly, because MySQL will have already compiled some information ahead of time that helps it rapidly find any record that matches a given guid. Because FeedWordPress uses the guid field in order to determine whether or not a post from one of your feeds has already been syndicated into your blog, it frequently needs to issue these searches. For a large installation like yours, creating the index should help provide a significant performance boost. The index purely has to do with how MySQL searches through the database records; it will not add, eliminate, or modify any information in your database.
I don't know how well this explains; the technical details of the indexing are pretty closely tied to the technical ins and outs of SQL-based relational databases. But the main thing I'd want to stress is that the option is very easy to try out, should have no side effects on the kind of data you see, and can be easily removed if you decide that you need to turn it off.
Thanks,
-C
Posted 5 months ago #
I will try it too.
Thanks again!
Posted 5 months ago #
As an added note, I had to increase my MySQL the max_allowed_packet to 8M in the my.cnf file. Some of the feeds were too big for the default setting.
Also, I switched from apache to nginx/php-fpm and it runs SO much better. I never have memory issues now.
Posted 1 month ago #
I am also having trouble with this plugin as it's immensely slowing down my site. I have also tried everything the plugin author has suggested in this thread and nothing really helped.
Has anybody tried out a cache solution with the site? I've read that the W3 total cache wipes out settings and syndication after a while so I am pretty reluctant to try it out.
You must log in to post.
