Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Plugin Slows Vanilla to a Crawl
This discussion is related to the SphinxSearch addon.
agcyphers Nooooop. ✭
edited January 2015 in Vanilla 2.0 - 2.8
I'm currently using Vanilla 2.1.7 with the latest version of the Sphinx Search plugin. I've installed and configured everything, but while the plugin is enabled my page load times are ridiculously slow (>1 minute per). Any idea on where to start fixing this?
- Operating system: CentOS Linux 6.6
- Kernel and CPU: Linux 2.6.32-042stab090.4 on i686
- Processor information: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 4 cores
- System uptime: 1 hours, 08 minutes
- CPU load averages: 0.18 (1 min) 0.08 (5 mins) 0.02 (15 mins)
- CPU usage: 0% user, 0% kernel, 0% IO, 100% idle
- Real memory: 111.56 MB used, 1024 MB total
- Virtual memory: 0 bytes used, 1024 MB total
- Local disk space: 1.63 GB used, 100 GB total
- Server version: Apache/2.2.15 (Unix)
- Server built: Oct 16 2014 14:45:47
- mysql Ver 14.14 Distrib 5.1.73, for redhat-linux-gnu (i386) using readline 5.1
- PHP 5.3.3 (cli) (built: Oct 30 2014 19:56:14)
- Zend Engine v2.3.0
- [PHP Modules]
- bz2, calendar, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gettext, gmp, hash, iconv, json, libxml, mbstring, mysql, mysqli, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, readline, Reflection, session, shmop, SimpleXML, sockets, SPL, sqlite3, standard, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib
Also noticed that once the SphinxSearch settings page does finally load, it's showing that searchd isn't running, even though it is.
@mcu_hq Any ideas?
Just stabbing at the dark here:
Is sphinx and your database on the same machine?
Can you run xdebuger and profile one of the slow pages? I recall being able to use cachegrind to find out the slow spots: http://www.xdebug.org/docs/profiler
I haven't tested this with the version of vanilla you are using. I think I just got it working on v2.0 last year, so the plugin could be the cause of the problem - but I'm not sure where and how it would timeout.
I'll try the steps in #2, but to clarify some information:
1) Sphinx, MySQL, and Apache are all on this machine.
3) It's not any single page, it's every page. Dashboard and front-end alike.
Here's the item right before everything goes to pot, and the item that causes the lag, according to the Vanilla Debug plugin. The preceeding 4 queries for this dashboard page all took less than 0.02 seconds.
@mcu_hq Just a poke to make sure you've seen this. Forgive me, but I'm not familiar enough to know when the notifications go out.
I'm running SphinxSearch with Vanilla 2.1.7 and haven't noticed and performance issues.
I'd say it has something to do with the fact that Sphinx can't tell searchd is running, or possibly some misconfiguration along the way. Thanks for verifying that it does work well with 2.1.7, though. It's the last thing stopping me from turning off our olf vBulletin forum and moving totally over to Vanilla.
Yea - I can see the notifications. I'm sort of confused as to what your pastbin contains. It looks like it took 120s to load (btw, wouldn't your PHP engine issue a timeout by this time?) and then the vanilla debug printout out its configuration file?
OK, using CacheGrind, the slow down is definitely on connecting to the Sphinx server. 96.96 spent at SphinxClient->Status, SphinxClient->_Connect, php::fsockopen
Says that php:internal cannot be found...
I have verified that the fsockopen function is available.
The error in _Connect says that sphinxapi.php cannot be found, though it does exist and executable.
I have intentionally set my PHP timeout very high for debugging a separate issue, and it just happened to be useful in this issue as well. This site isn't production.
I've also run a test via SSH with "search dog" and all is well.
Yes, it still says on the config page that searchd isn't running, though I have verified that it is.
I have also verified that searchd is listening on port 9312.
Bah. I fixed it. I forgot that I had restricted localhost traffic using the firewall. So, in short, make sure port 9312 is open with both source and destination 127.0.0.1.
Sorry for the trouble.
But I do get the following error now:
Query failed: failed to read searchd response (status=2610, ver=11825, len=775368041, read=70).
OK, all done. Works perfectly now. My issue was that, with the version of Sphinx I was using, I had to change to port definition. The documentation I was reading said that the appropriate definition was "9312:mysql41", however, that opens port 9312 for SphinxQL and not the Sphinx API. Removing :mysql41 addressed the issue.
Thanks for all of your patience, @mcu_hq This plugin has saved me.
Sorry, both of the above port definitions should have "listen = " in front them.
Thanks for reporting back with what you found!
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Glad you got it solved. Be sure that you copied the sphinxapi.php file that was bundled with your downloaded version of sphinx over the one that ships with the plugin.
Yup. Sure did. Thanks again!