Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed up Discussion Search FullTextGambit as it is too slow #1888

Closed
wants to merge 4 commits into from
Closed

Speed up Discussion Search FullTextGambit as it is too slow #1888

wants to merge 4 commits into from

Conversation

meezaan
Copy link

@meezaan meezaan commented Sep 20, 2019

Fixes flarum/issue-archive#240 (potentially)

Changes proposed in this pull request:

The relevance based search in the original gambit has a huge performance impact (a negative one), so it actually makes Flarum unusable on large data sets. As an example, on our database, the original query took 105s to return results. The one in this PR takes 2-3s.

Reviewers should focus on:

Screenshot

Confirmed

  • [ x] Frontend changes: tested on a local Flarum installation and in production with 20m posts.
  • [ x] Backend changes: tests are green (run composer test).

@meezaan
Copy link
Author

meezaan commented Sep 26, 2019

So the unit tests will obviously fail because the query is different.

@franzliedke
Copy link
Contributor

Have you experimented with removing other, smaller parts of the query, e.g. the IN BOOLEAN MODE? I would expect a fulltext index to still perform better than a LIKE query.

@franzliedke
Copy link
Contributor

@meezaan Also, can you experiment with reverting #1741 and then amending it so that this test still passes?

@meezaan
Copy link
Author

meezaan commented Oct 2, 2019

@franzliedke Thanks for the feedback. I will try and find the time to do this, but just FYI I we are working on an Elastic Search extension and that is my priority (because I will be moving on shortly). As it stands, the results we are getting with this SQL are good enough - but other parts slow down with the large data - the Following page, loading large tags, etc. and and there's no text search there - it's the late order by clause that kills us, and what we really want to do is have enough WHERE clauses to reduce the number of results to order. Adding @tariqwalji here who will be taking over from me.

@stale
Copy link

stale bot commented Jan 18, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

@stale stale bot added the stale Issues that have had over 90 days of inactivity label Jan 18, 2020
@meezaan
Copy link
Author

meezaan commented Jan 20, 2020

I will close this - this problem has likely been addressed using Elastic Search? @tariqwalji?

@stale stale bot removed the stale Issues that have had over 90 days of inactivity label Jan 20, 2020
@luceos
Copy link
Member

luceos commented Jan 20, 2020

We settled on reverting the change that included the discussion subject and will investigate alternative solutions like a delegated search driver (perhaps something similar to Laravel Scout) before (or soon after) stable.

@luceos luceos closed this Jan 20, 2020
@meezaan
Copy link
Author

meezaan commented Jan 22, 2020

Thanks @luceos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Slow loading searches and tags on large data sets
3 participants