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

Virtus accounts for 45% of view rendering time for large result sets #767

Closed
bkazez opened this issue Dec 30, 2017 · 6 comments
Closed

Virtus accounts for 45% of view rendering time for large result sets #767

bkazez opened this issue Dec 30, 2017 · 6 comments

Comments

@bkazez
Copy link

bkazez commented Dec 30, 2017

See attached performance analysis. Virtus seems to be adding a significant slowdown when processing a result set of 10k smallish documents. Note that the attached is just for rendering a single .erb.html template and does not include time spent querying es or even processing the results.

I am porting legacy code from PHP/MySQL and right now it performs much better on PHP/MySQL (~10x).

Eventually I will implement pagination using search_after, but I believe I will still have these issues. For heavy-duty use, do implementors need to simple use the client directly? I am just parsing array fields into a <table> and so do not require much fanciness on the part of the Rails library.

screen shot 2017-12-30 at 22 21 17

@nilbus
Copy link
Contributor

nilbus commented Jan 1, 2018

solnic/virtus#287 discusses performance in Virtus, which is a little worse in Ruby 1.9, and a lot worse when loading the binding_of_caller gem. I'm not sure if you're being affected by these or not, but that's worth looking into.

It is possible to use Virtus without the type coercer, but not in Elasticsearch::Persistence::Model without modifying the gem to use Virtus.model(coerce: false).

@estolfo
Copy link
Contributor

estolfo commented Aug 15, 2018

@bkazez @nilbus The ActiveRecord persistence pattern (Elasticsearch::Persistence::Model) has been deprecated and removed in version 6.0 of the elasticsearch-persistence gem so this issue is no longer relevant. If you don't mind, I'd like to close it.

@estolfo estolfo added the waiting-for-user Waiting for user input to proceed label Aug 15, 2018
@bkazez
Copy link
Author

bkazez commented Aug 15, 2018

I am actually using Elasticsearch::Persistence::Repository.

@estolfo
Copy link
Contributor

estolfo commented Aug 16, 2018

@bkazez I apologize, my mistake. I must have looked at the last comment and noticed that Elasticsearch::Persistence::Model was cited. Is there anything you think the elasticsearch-persistence gem can do about this or is the performance issue with the Virtus gem itself?

@bkazez
Copy link
Author

bkazez commented Aug 16, 2018 via email

@estolfo
Copy link
Contributor

estolfo commented Aug 17, 2018

@bkazez ok, I think the performance issue lies with Virtus, not with the elasticsearch-rails gems. If I'm mistaken, please let me know where you notice a bottleneck or if I can close this issue. Thanks!

@estolfo estolfo closed this as completed Sep 4, 2018
@estolfo estolfo removed the waiting-for-user Waiting for user input to proceed label Sep 4, 2018
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

No branches or pull requests

3 participants