- This topic has 6 replies, 2 voices, and was last updated 9 years, 1 month ago by
.
-
Posts
-
hello, when the index table process is going on an error stops the process with this message:
Status: 404
Code: Not FoundHi,
I’m not sure, but it might indicate a missing file, or something conflicting with the creation process.
First try to change the following configuraiton, and then re-try: http://i.imgur.com/I92mCiR.png
This configuration will try to reduce the load and potentially filter any shortcodes.If that does not change anything, I might need temporary FTP and admin access to be able to check the issue directly. I will then try to debug the indexing process directly via FTP, to see if there is any unknown conflict there.
Hi,
Thank you very much for the details, the problem is going to be something else, I’m not sure yet. I’m not able to make changes to the plugin files via FTP, can you please check the FTP access?
The problem I believe is somewhere around getting the document IDs which to be indexed, or the index table size might be simply too big for the server to handle, I’m not sure yet. After I’m able to do some debugging, I will have more information, and hopefully the issue is fixable.
hello, i changed the plugin file ownerships for the ftp user i gave you. now you should be able to make changes on the ftp. please check again and let me know what the problem is and how to fix. i like this plugin very much and i hope that i will be able to use it no matter the database size..
i wonder if it is possible to initiate the indexing process from the command line of the server. i suspect that some problems may occur when the process is sending data to the browser. this way i can start the indexing process from the crontab
Hi,
Thank you for correcting the information. I was able do debug the process, here is what I have found.
The issue is not the actual indexing process, this is very good news. The slowness comes from when the index tries to calculate how many rows are indexed, and how many more needs to be indexed. I’ve done some research on this, and turns out that some database engines does not store the row counts, but instead they have to run the query every time, which takes some time in such huge data sets.
The good news is, that most of this counting is informative only, it has no effect on the indexing outcome. I have disabled these counters programatically, and it already made a huge difference in performance. One table operation however must remain, for the index to be able to select which posts to index next, without that it’s not going to work.
The ‘items not indexed’ counter is still active, so you can check if there is any items remaining to index: http://i.imgur.com/wAEqoCs.pngSetting the indexing limit to 50 worked correctly, with an occasional stops, but I was able to finish the indexing. Now every post is indexed, and new ones are indexed automatically when saving them.
Now everything should be indexed, I’ve otpimized the configuration as much as possible.
- You must be logged in to reply to this topic.