Hi Miruna, we are having moved the search indexes for our LF Repo onto a separate server and monitored the CPU which  triggered the search via API in a Portlet hosted by IBM WebSphere. 

There was no activity on the CPU of the host we have moved the search indexes too.

We used LF Client search we then saw the CPU spike in activity. Which led us to believe the API was NOT using the search.

There is a tonne of confusement here on how the actual JRA API functions and works and Laserfiche Support have asked us to post our questions here.

Our environment consists of a : Laserfiche server 9.2 (holds the repository) - Search Server holds the search for the repository > Portal Server (hosts the portlet which uses the LF JRA API) > Webservers  > Webseal.

We have done wireshark traces and we learnt the bottle neck was at the Laserfiche Server.

We have also checked for fragmentation on the LF Search Indexes as stated here:

https://www.laserfiche.com/support/webhelp/Laserfiche/9.2/en-US/AdminGuide/LFAdmin.htm#search_engine_configuration_utility.htm%3FTocPath%3DLaserfiche%2520Administration%2520Guide%7CAppendix%2520C%253A%2520Laserfiche%2520Utilities%7C_____5

We are not knowledgeable on the Microsoft SQL 2012 Side to check for fragmentation on the MS Side of the LF Repo database,.

Rebecca will post more information soon about the search query she is using and hopefully we can get advice on how to optimise and improve response time for the slow searches.

Or if we are missing something obvious please comment.

Thanks

Hi Miruna, Here are some examples of some searches that are run by the portlet:

Query:

{LF:lookin="\Technical Support\Firmware and Patch\", subfolders="1"} & {[Document]:[Products](any) in ("404495"), [Audience](any) in ("technician"), [Date Published] <= "2015/05/06", [Is Published] = "Yes"} & ({LF:Tags = "Technical Support Employee"} | {LF:Tags = "Technical Support Printer"} | {LF:Tags = "Technical Support ICT"} | {LF:Tags = "Technical Support Production"} | {LF:Tags = "Technical Support Default"} | {LF:Tags = "Technical Support Everyone"}) & {LF:name="*", Type="D"} - {LF:lookin="\Technical Support\Firmware and Patch\Technical Support Archived\", subfolders="1"}

In this instance the time I have recorded to obtain a Laserfiche session is 61ms and another 12729ms it run the search. The search returned 108 documents. To run the same query in the Laserfiche client took less than 2s.

similar query:

{LF:lookin="\Technical Support\Product Solution\", subfolders="1"} & {[Document]:[Products](any) in ("TRANSFORMERV3"), [Audience](any) in ("technician"), [Date Published] <= "2015/05/06", [Is Published] = "Yes"} & ({LF:Tags = "Technical Support Employee"} | {LF:Tags = "Technical Support Printer"} | {LF:Tags = "Technical Support ICT"} | {LF:Tags = "Technical Support Production"} | {LF:Tags = "Technical Support Default"} | {LF:Tags = "Technical Support Everyone"}) & {LF:name="*", Type="D"} - {LF:lookin="\Technical Support\Product Solution\z_Tech Support Archived\", subfolders="1"}

This instance of this query the time to obtain a Laserfiche session was 5103ms and to run the search 1061ms and returned 29 documents. To run the same query in Laserfiche client took again less than 2 seconds.

So while the query may look complicated it doesn't take a long to run in the client and the point is running the same query twice via the portlet can give quite different time responses.

As is clear by just the difference seen in obtaining  the session. I didn't previously post a example of the query as I thought it would distract from the issue of the variance in time responses despite what the query is.

FYI this same app has been running for more than a year and it is only since February that the performance has deteriorated. This around this time we upgraded the server to 9.2. However the load on the server may also have increased at that time as well so we are trying to work out how to regain the response times we use to see. 

Also I noticed that in the session class of the JRA API for 9.2 it still has the versionName equaling "LFJRA/8.3". Has their actually been any changes to the JRA since Laserfiche 8.3?

cheers,

JRA was updated for SDK 9.0 and again for SDK 9.2. You should have a JRA-9.2.0.jar installed under the SDK 9.2 directory. I don't know if this would address any of your items, but it has been updated. 

To the differences in search between jRA and the Client, I'd want to check how exactly you are running the search in the Client. Are you just pasting the same query into the advanced block, or are you using the search blocks in any way? Search was made more efficient through the search blocks in Client and Web Access 9.1, so if you're using them it might not be the same query as it was before. 

Another thing to check is the Search settings in your Client instance. In Tools\Options\Search there are a number of settings that don't show up in the query itself but impact how the search is run on the Server. You might try comparing those to your search code in jRA and updating to match. They should all have corrosponding properties you can set in jRA. 

Hi Justin,

Thank you for your responses I appreciate any help/suggestions I can get. 

I am using SDK 9.2 but noticed when I was looking in Laserfiche Admin Activity -> sessions section and observe the connections from my portlet that for the user that my portlet connects with it displays the version as "LFJRA/8.3" under the Application column and on closer inspection the Session java class in JRA-9.2.0.jar it still says "LFJRA/8.3" as the value for the versionName field. That is why it made me wonder whether or not there had actually been any updates to the JRA API.

When I tested my search in the client I used the advanced query option and pasted it in there. I just tested performing the search using the query the search blocks creates and it did order the query slightly differently. It also didn't give me the option to use the "(any) in" clause for products and audience and set the Type for document search to "DB" instead of my "D". However, despite the slight differences it ran they query just as fast, as far as I could tell, as they both run in under 2s which I am really happy with.

Here is the query the search block created:

 ({[Document]:[Audience]="technician", [Is Published]="Yes", [Products]="404495"} & {[Document]:[Date Published] <="05/05/2015 00:00:00"} & {LF:Name="*", Type="DB"} & ({LF:Tags="Technical Support Default"} | {LF:Tags="Technical Support Employee"} | {LF:Tags="Technical Support Everyone"} | {LF:Tags="Technical Support ICT"} | {LF:Tags="Technical Support Printer"} | {LF:Tags="Technical Support Production"}) & {LF:LOOKIN="LFWebDocs\Technical Support\Firmware and Patch"}) - {LF:LOOKIN="LFWebDocs\Technical Support\Firmware and Patch\Technical Support Archived"}

I just don't understand the vast differences I see via API search as sometimes this search, with perhaps a different product set as the only difference takes up to 25s to be returned. So I would love to better understand the difference between how the API search works via the Client search. I realise the API search will be slower but I would expect it to be this slow.

cheers,

Rebecca

Hi All,
           Thanks for your replies so far.

Case Logged: 167026

I hope we get some more information this time.

Thanks