Alfresco discussion and collaboration. Stick around a few hours after asking a question.
Official support for Enterprise subscribers: support.alfresco.com.
Join in the conversation by getting an IRC client and connecting to #alfresco at Freenode. Our you can use the IRC web chat.
More information about the channel is in the wiki.
More help is available in this list of resources.
2019-12-10 11:48:30 GMT <hi-ko> I can't believe michaelsuzukisagi's answer in https://github.com/Alfresco/SearchServices/issues/234: He suggests more hardware / sharding although Alfresco 5.2/solr4 was 2-5 times faster without sharding
2019-12-10 11:48:31 GMT <alfbot> Title:Issues · Alfresco/SearchServices · GitHub (at github.com)
2019-12-10 11:59:36 GMT <hi-ko> doesn't fit well with https://docs.alfresco.com/5.2/references/sharding-best-practices.html
2019-12-10 11:59:38 GMT <alfbot> Title:Best practices for setting up sharded Solr indexes | Alfresco Documentation (at docs.alfresco.com)
2019-12-10 12:02:01 GMT <alfresco-discord> <yreg> now that you brought that up, Alfresco will probably consider that "documentation" as broken and will probably fix it by removing the "0" from "50 mio documents" 😄
2019-12-10 12:02:38 GMT <hi-ko> yreg: I'm afraid you're right
2019-12-10 12:03:33 GMT <angelborroy> We are working on that
2019-12-10 12:03:44 GMT <hi-ko> I'm pretty disappointed with ASS's search performance compared to 5.2/solr4
2019-12-10 12:03:48 GMT <angelborroy> It’s not easy to have a number for everyone
2019-12-10 12:04:21 GMT <angelborroy> Interesting blog post in
2019-12-10 12:04:21 GMT <angelborroy> https://hub.alfresco.com/t5/alfresco-content-services-blog/sizing-my-alfresco-search-services/ba-p/294052
2019-12-10 12:04:22 GMT <alfbot> Title:Alfresco Search Services Solr (at hub.alfresco.com)
2019-12-10 12:05:38 GMT <hi-ko> I would bet that it would be possible to get the previous scalability by removing some design flaws.
2019-12-10 12:06:18 GMT <angelborroy> We are also working on a new desing to improve performance
2019-12-10 12:12:12 GMT <alfresco-discord> <MorganP> I have some blogs on the sharding since months as well, didn't get the time to finish them 😦
2019-12-10 12:13:28 GMT <hi-ko> I read michael's blog once published but there is nothing said about search performance.
2019-12-10 12:13:48 GMT <hi-ko> ASS behaves very strange compared with 5.2: the system is idle most of the time (cpu/storage) while processing searches. So it may be a ugly work around to have 4x2 cpu cores for 4 jvms instead of one machine having 8 cores.
2019-12-10 12:14:30 GMT <hi-ko> managing shards makes everything more complicated and I was not able to configure SSL
2019-12-10 12:23:04 GMT <AFaust> hi-ko: In the query you listed in the GitHub issue (after I last checked yesterday morning) you have various facets on custom ECM4U fields. Does your model include the proper <facetable>true</facetable> definitions for these? Is the query (significantly) faster if you disable faceting?
2019-12-10 12:23:51 GMT <AFaust> I can imagine that there might be some low-level changes that make the fallback behaviour when <facetable> is not set at all (neither false nor true) less efficient in SOLR 6 compared to 4
2019-12-10 12:24:51 GMT <AFaust> And I know from experience that a lot of people are pretty unaware of these added model elements or even wilfully ignore them as "it always worked fine without"
2019-12-10 12:27:38 GMT <hi-ko> AFaust: I will check query times with disabled faceting
2019-12-10 13:31:42 GMT <hi-ko> AFaust: I removed the facet arguments from the query. The only difference is that the result is take from the result cache if the exact same search has been executed some attempts before
2019-12-10 13:32:00 GMT <hi-ko> but the uncached single word search takes still 15 sec
2019-12-10 13:36:07 GMT <hi-ko> s/15/55/
2019-12-10 13:48:30 GMT <AFaust> Also tried without highlighting?
2019-12-10 13:48:58 GMT <AFaust> Honestly, there is something really wonky in your case. I have never seen ASS behave that way in any scaling test, including 1.4.0
2019-12-10 13:51:13 GMT <AFaust> E.g. with the 100mio test, I could reliably reproduce uncached query time of ~130s with facets and sorting enabled (on large-ish result set), but when I removed faceting, it improved dramatically to ~30s (with sort) or ~5s (no sort)
2019-12-10 13:51:34 GMT <AFaust> And these are values from the unsharded initial test.
2019-12-10 13:53:00 GMT <AFaust> Initial sort performance (on cm:name) was / is abysmal because of the huge index and memory/IO cost of essentially loading all cm:name into memory / cache.
2019-12-10 13:54:47 GMT <AFaust> above values were from initial tests without filter queries (which are/were my main priority)
2019-12-10 14:05:04 GMT <hi-ko> without highlighting and facets the query takes ~30 sec for uncached queries; on solr4 with highlighting and facets ~6 sec
The other logs are at http://esplins.org/hash_alfresco