Hi Bill, The issue you are seeing doesn't sound to be the same as the original issue in this thread. The behavior that was fixed in 6.3 was a behavior where the *Collection homepage* loaded extremely slowly if you had Items that had large number of bitstreams/thumbnails. The fix was to be much smarter about when to load Thumbnails/bitstreams into memory (and it was a fix to the Java code under the XMLUI, so it applied to all themes): https://github.com/DSpace/DSpace/pull/2016
The behavior you seem to be describing sounds different... you are talking about the /community-list page with a large number of collections/communities, and a Community page with a large number of sub-communities/collections. So, I'm not surprised that this specific 6.3 optimization had no effect -- as it was only for Collection homepages. I cannot say for certain what is behind the behavior you are seeing -- it's very possible that it's semi-related in that DSpace may be loading too many objects into memory at once (which slows down the application, especially with the addition of Hibernate in 6.x). But, in your situation, it sounds like maybe DSpace is loading too many Communities/Collections at once (whereas the bug fixed was about ensuring DSpace didn't load too many bitstreams into memory at once) All in all, I think we may need to create a new ticket & begin a new investigation into why this other performance behavior is occurring. Hopefully it's something we can track down and fix in a 6.4 release. - Tim On Fri, Sep 28, 2018 at 10:11 AM Bill Tantzen <wile...@gmail.com> wrote: > I'm very tardy jumping back into this party, but here's an update: I just > upgraded my dev site to version 6.3, and the speed problems persist. I > have made sure to optimize the mets requests in my theme, but that's > actually a moot point, because the slowness is equally apparent even in the > Default Reference Theme and the Atmire Mirage2 Theme (which I assume has > been optimized, in v6.3, correct?). > > For /community-list with ~1500 collections + communities and 62K items, > the page load time is minutes. For our main community page, which contains > the bulk of those sub-communities and collections (maybe 90%), the page > load time is about 15 seconds. That's still too slow to put into > production, but makes me wonder why the difference in speed is so vast > compared with the number of children in each case. > > Also, in one respect, the performance is even worse now. If you dig up an > earlier thread that I started, you will remember that the speed is just > fine when logged in as an admin. This is no longer the case, as there is > no difference in speed between admin and anonymous users. > > Naturally, this is causing us to sit on v5.x for now, but since the rest > half of v7 is based on v6, we need to figure this out! > > Cheers, > Bill > > On Thu, Apr 12, 2018 at 1:02 AM Ying Jin <elsa....@gmail.com> wrote: > >> Hi Tim, >> >> I have the fileSec updated so it only retrieve THUMBNAILs and it >> significantly improved the page loading. Though some of our static >> thumbnails broken, I am sure I can find another way to fix that. >> >> Cheers, >> Ying >> >> On Wednesday, April 11, 2018 at 10:19:10 AM UTC-5, Tim Donohue wrote: >>> >>> Hi Ying, >>> >>> Looking forward to hearing what you find out. >>> >>> In the meantime, I'd like to better understand this statement: >>> >>> "For the thumbnail part, it is still a problem for us as I mentioned >>> earlier, we have special theme needs to load all the thumbnails for the >>> Gallery theme and TEI theme." >>> >>> Could you describe how you are using/displaying thumbnails in the >>> Gallery theme and TEI theme? Are you displaying multiple thumbnails *per >>> item* on the Community/Collection homepages (e.g. in Recent Submissions) in >>> these themes? If so, is there a limit to the number of thumbnails you >>> display per Item (or a limit to the number of thumbnails that tend to exist >>> per item)? Or is each item still represented by a single thumbnail on the >>> Community/Collection homepage? Do you have links you could share with us >>> regarding these themes, so that we can better understand the use case >>> here? >>> >>> Obviously, we don't want to include changes in DSpace 6.3 that would >>> improve performance but also break specific theme use cases. >>> >>> Thanks >>> >>> - Tim >>> >>> On Wed, Apr 11, 2018 at 10:06 AM Ying Jin <elsa...@gmail.com> wrote: >>> >>>> Hi Tim, >>>> >>>> Thanks very much for the detailed information and great suggestion! It >>>> makes sense to not load original bundles or any other bundles that are not >>>> related to the page view. >>>> >>>> Now I remembered I customized the "sections= >>>> dmdSec,fileSec&fileGrpTypes=THUMBNAIL" part long time ago for some >>>> customizations as we need more info from mets.xml than what it is provided >>>> by default. I need to go and check what I have changed and report back! >>>> >>>> For the thumbnail part, it is still a problem for us as I mentioned >>>> earlier, we have special theme needs to load all the thumbnails for the >>>> Gallery theme and TEI theme. >>>> >>>> I posted a code update on ticket about the READ_ONLY mode. For >>>> read-only transactions, we should set Hibernate flush mode to MANUAL. >>>> However, DSpace missed several places to change the default AUTO to MANUAL, >>>> that's why we got lots of partial-flushing in the log. I will post more >>>> findings on the tickets. >>>> >>>> Best, >>>> Ying >>>> >>>> >>>> >>>> On Wednesday, April 11, 2018 at 9:13:10 AM UTC-5, Tim Donohue wrote: >>>> >>>>> Hi Ying (I'm copying back in DSpace-Tech, as I'd like this discussion >>>>> to stay on-list), >>>>> >>>>> Looking back at this thread, I see you mentioned the custom MASTER >>>>> bundle earlier as well. I had forgotten that. >>>>> >>>>> The core issue (that I resolved in >>>>> https://github.com/DSpace/DSpace/pull/2016) is actually not directly >>>>> related to Hibernate. The issue we discovered is the XMLUI themes/aspects >>>>> are loading and parsing bundles that *are unnecessary to display the >>>>> Collection homepage*. So, in PR#2016, I resolved this by ensuring that, >>>>> on the Collection/Community homepages, the XMLUI themes/aspects never load >>>>> the ORIGINAL bundle content (and only load up the first bitstream in the >>>>> THUMBNAIL bundle). >>>>> >>>>> Since this didn't improve your performance, I'd venture to guess that >>>>> the XMLUI theme you are using is either purposefully or accidentally >>>>> loading up you custom MASTER bundle (and looping through all the objects >>>>> in >>>>> that bundle). Assuming you don't need any information about the MASTER >>>>> bitstreams on the Collection homepage, the fix would be to ensure your >>>>> theme is *only* loading/using the THUMBNAIL bundle (as likely your >>>>> Collection homepages will want to display thumbnails for items that have >>>>> them). >>>>> >>>>> This is usually controlled at the *theme* level in the XMLUI. >>>>> >>>>> For example, our demo.dspace.org site uses the Mirage 2 theme. The >>>>> Mirage 2 theme specifically only loads the THUMBNAIL bundle for items on >>>>> the Collection homepage. You can see this by viewing the HTML source of a >>>>> Collection's homepage, e.g. >>>>> http://demo.dspace.org/xmlui/handle/10673/2 >>>>> >>>>> In the HTML source, where each Item is displayed (in the Recent >>>>> Submissions section) you'll see an HTML comment that says: >>>>> <!-- External Metadata URL: >>>>> cocoon://metadata/handle/10673/80/mets.xml?sections=dmdSec,fileSec&fileGrpTypes=THUMBNAIL--> >>>>> >>>>> >>>>> This comment shows where the metadata was gathered for this Item. In >>>>> fact, you can paste that URL into your browser to see the Item's metadata >>>>> (in METS format): >>>>> >>>>> http://demo.dspace.org/xmlui/metadata/handle/10673/80/mets.xml?sections=dmdSec,fileSec&fileGrpTypes=THUMBNAIL >>>>> >>>>> The key point here is that URL includes a parameter >>>>> "fileGrpTypes=THUMBNAIL". That parameter restricts the theme to ONLY >>>>> using >>>>> the THUMBNAIL bundle of Items when creating the Recent Submissions lis on >>>>> a >>>>> Collection/Community homepage. >>>>> >>>>> My guess here is that your local theme may NOT include this key >>>>> optimization. If instead, the URL were to just point at the "mets.xml", >>>>> then by default your theme would load ALL bitstreams in ALL bundles for >>>>> ALL >>>>> items displayed in that Recent Submissions listing. As you probably can >>>>> guess, that would take a VERY LONG time if you have hundreds of >>>>> bitstreams...and that time is wasted unless your theme actually needs to >>>>> display something from those bitstreams. The reason this behavior occurs >>>>> in >>>>> the XMLUI is that the XMLUI itself doesn't know which "data" the theme >>>>> requires. If the theme just asks for the "mets.xml", then the XMLUI will >>>>> assume the theme needs *all information about the item* (including all >>>>> bitstreams/bundles). So, it's up to the theme to properly tell the XMLUI >>>>> which data to load. >>>>> >>>>> In the Mirage2 theme, this setting can be found here: >>>>> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-xmlui-mirage2/src/main/webapp/xsl/aspect/artifactbrowser/common.xsl#L214 >>>>> >>>>> >>>>> In the Mirage theme, this setting can be found here (in the >>>>> dri2xhtml-alt base theme): >>>>> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-xmlui/src/main/webapp/themes/dri2xhtml-alt/aspect/artifactbrowser/common.xsl#L157 >>>>> >>>>> If your theme is based on the original dri2xhtml.xsl base theme (which >>>>> is less likely), you'd find that setting here: >>>>> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-xmlui/src/main/webapp/themes/dri2xhtml/structural.xsl#L3600 >>>>> >>>>> >>>>> Notice how in all of these themes, the theme always makes sure to >>>>> append "fileGrpTypes=THUMBNAIL" when in the "summaryList" mode (this mode >>>>> is the one used for Recent Submissions listings, search results, etc.). >>>>> Obviously, if a specific theme requires more than just THUMBNAIL >>>>> bitstreams >>>>> in the Recent Submissions listing, you can append other Bundle names to >>>>> the >>>>> "fileGrpTypes". But, beware that doing so will (by default) tell the >>>>> XMLUI >>>>> to loop through all bitstreams in that bundle to ensure they are ALL >>>>> included in the DRI XML output so the Theme can select which one(s) to >>>>> display. >>>>> >>>>> I'd recommend double checking your theme(s) to ensure they all include >>>>> this optimizatio. My guess is that one or more of them likely do not, >>>>> which >>>>> may be why bitstreams in your MASTER bundle end up getting loaded, and end >>>>> up affecting the performance of your Collection/Community homepages. >>>>> >>>>> I hope that helps! >>>>> >>>>> Tim >>>>> >>>>> On Tue, Apr 10, 2018 at 8:02 PM Ying Jin <elsa...@gmail.com> wrote: >>>>> >>>> Hi Tim, >>>>>> >>>>>> >>>>>> I have the code applied and tested on our development site. It's a >>>>>> great improvement for the XMLUI code. Unfortunately, most of our >>>>>> collections still slow loading even we have only 3 recent submissions for >>>>>> the collection home page. >>>>>> >>>>>> We have our master files preserved with items, that's the most of our >>>>>> bitstreams come from. The masters are hidden from end users and have no >>>>>> thumbnails or txt derivatives. Since the code change is limiting number >>>>>> of >>>>>> thumbnails to load, it doesn't quite apply to our situation. >>>>>> >>>>>> Some other situations is, we have one collection with gallery theme >>>>>> which we have to load all 300+ thumbnails; Another is TEI theme, which we >>>>>> have more about 790 original bitstreams and masters each item, we need to >>>>>> load all the thumbnails for the TEI generation too. >>>>>> >>>>>> Hope this helps, >>>>>> >>>>>> Best, >>>>>> Ying >>>>>> >>>>>> On Tue, Apr 10, 2018 at 9:20 AM, Tim Donohue <tdon...@duraspace.org> >>>>>> wrote: >>>>>> >>>>> Hi Ying (and all), >>>>>>> >>>>>>> We now have a possible solution to this Collection homepage slowness >>>>>>> in DSpace 6.2. It does require minor Java code changes to the XMLUI >>>>>>> (in a >>>>>>> single class). But, if you have time/willingness, it might be worth >>>>>>> testing on your end prior to the new DSpace release (version 6.3) -- >>>>>>> that >>>>>>> way we can ensure it completely solves the problem on your site. >>>>>>> >>>>>>> Here's the Pull Request (PR) including the necessary code changes: >>>>>>> https://github.com/DSpace/DSpace/pull/2016 >>>>>>> And here's a downloadable "diff" of the changes included in that PR: >>>>>>> https://github.com/DSpace/DSpace/pull/2016.diff >>>>>>> >>>>>>> Let us know if you are able to test it out. If so, please comment >>>>>>> either in this email thread or on the ticket and let us know if it >>>>>>> solves >>>>>>> the issue: https://jira.duraspace.org/browse/DS-3883 >>>>>>> >>>>>>> Thanks, >>>>>>> Tim >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 4, 2018 at 10:59 AM Terry Brady <terry...@georgetown.edu> >>>>>>> wrote: >>>>>>> >>>>>> This sounds like a significant issue that should be tracked for the >>>>>>>> next DSpace release. I created a Jira ticket to track it. I >>>>>>>> referenced >>>>>>>> this thread in the ticket. >>>>>>>> >>>>>>>> https://jira.duraspace.org/browse/DS-3883 >>>>>>>> >>>>>>> On Tue, Apr 3, 2018 at 12:15 PM, Ying Jin <elsa...@gmail.com> wrote: >>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> Hi Hugo, >>>>>>>>> >>>>>>>>> Thanks for the advice. Somehow, we don't have problem with item >>>>>>>>> page but collection page. >>>>>>>>> >>>>>>>>> We updated the collection page with 3 recent submissions instead >>>>>>>>> of 20 and zipped most of our masters so that the number of bitstreams >>>>>>>>> for >>>>>>>>> each item decreased. It helped a lot but its a temporary solution. It >>>>>>>>> would >>>>>>>>> be great if DSpace performs well with the setup we used to have. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Ying >>>>>>>>> >>>>>>>> On Tue, Apr 3, 2018 at 8:15 AM, Hugo Carlos <hugo....@ufabc.edu.br> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I think we had similar issues with xmlui at the exhibition of >>>>>>>>>> some itens we imported from scopus, where there are a large group of >>>>>>>>>> author >>>>>>>>>> (2000 people at the CERN workgroup, for example,as you can see from >>>>>>>>>> the >>>>>>>>>> attached image). We had modified the item-view.xml to look only for >>>>>>>>>> 3 of >>>>>>>>>> the author. (as seen in second image with the same registry), and it >>>>>>>>>> apparently solved the issue of performance when to exhibit those >>>>>>>>>> itens. >>>>>>>>>> Maybe if you limit the bitstreams to look when xml is building the >>>>>>>>>> exhibition could solve your issue? >>>>>>>>>> >>>>>>>>>> [image: image.png] >>>>>>>>>> >>>>>>>>>> [image: image.png] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _________________________________ >>>>>>>>>> Hugo da Silva Carlos >>>>>>>>>> Bibliotecário >>>>>>>>>> Universidade Federal do ABC >>>>>>>>>> 55+ (11) 4996-7934 >>>>>>>>>> >>>>>>>>> 2018-04-02 17:30 GMT-03:00 Ying Jin <elsa...@gmail.com>: >>>>>>>>>> >>>>>>>>> Hi Tom, >>>>>>>>>>> >>>>>>>>>>> Sorry for late reply. Somehow I missed your posting and just >>>>>>>>>>> found it by doing a search. >>>>>>>>>>> >>>>>>>>>>> "would it be possible for any of you to provide an anonymised >>>>>>>>>>> and cleaned database that you can share with us? Make sure the >>>>>>>>>>> database >>>>>>>>>>> does not contain any sensitive information. I'm sure such a >>>>>>>>>>> database will >>>>>>>>>>> also be useful for other (demo and testing) purposes and the >>>>>>>>>>> development of >>>>>>>>>>> DSpace 7." >>>>>>>>>>> >>>>>>>>>>> ==== Yes, I would love to have an anonymised and cleaned >>>>>>>>>>> database to share with you. I can't include everything we have, >>>>>>>>>>> however, it >>>>>>>>>>> would include several collections that we are experiencing the >>>>>>>>>>> performance >>>>>>>>>>> problems. I am wondering if it is easier sending them out as simple >>>>>>>>>>> archive >>>>>>>>>>> format and you can ingest into whatever database you have? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> "for the Collection and Community pages can you try setting the >>>>>>>>>>> context mode to READ_ONLY in the getValidity(), addPageMeta() and >>>>>>>>>>> addBody() >>>>>>>>>>> methods of classes >>>>>>>>>>> org.dspace.app.xmlui.aspect.artifactbrowser.CollectionViewer >>>>>>>>>>> and org.dspace.app.xmlui.aspect.artifactbrowser.CommunityViewer. >>>>>>>>>>> Here's an example of how to do that: >>>>>>>>>>> https://github.com/DSpace/DSpace/pull/1694/files#diff-fb7249e19a6a8652860795d8fd59cd9e >>>>>>>>>>> " >>>>>>>>>>> >>>>>>>>>>> ==== I will give it a try and see if it is indeed make any >>>>>>>>>>> difference of our problem. Although I think the ultimate solution >>>>>>>>>>> might be >>>>>>>>>>> to not loading unnecessary objects (in our case, it may not >>>>>>>>>>> necessary to >>>>>>>>>>> load all the bitstreams for a collection home page; ) >>>>>>>>>>> >>>>>>>>>>> "unfortunately the class responsible for the /community-list >>>>>>>>>>> page already uses the READ_ONLY mode ( >>>>>>>>>>> https://github.com/dspace/DSpace/blob/dspace-6_x/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/artifactbrowser/CommunityBrowser.java#L245). >>>>>>>>>>> But the fact that your number of (partial-)flushes is still so >>>>>>>>>>> high, I >>>>>>>>>>> wonder if there is still another place hibernate is loading so many >>>>>>>>>>> objects. However as a workaround, you could enable caching of that >>>>>>>>>>> /community-list page by setting the xmlui.community-list.cache >>>>>>>>>>> property in >>>>>>>>>>> dspace.cfg to true ( >>>>>>>>>>> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L1917 >>>>>>>>>>> )." >>>>>>>>>>> >>>>>>>>>>> ==== Is there any configuration for the cache of collection >>>>>>>>>>> page? I thought they are enabled by default but from the page >>>>>>>>>>> loading, it >>>>>>>>>>> doesn't seem like the pages are cached ... >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Ying >>>>>>>>>>> >>>>>>>>>>> On Sun, Mar 11, 2018 at 5:39 PM, Tom Desair <tom.d...@atmire.com >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>> Thanks all, this is really useful information! >>>>>>>>>>>> >>>>>>>>>>>> Since in both cases most time is lost on executing "flushes" or >>>>>>>>>>>> "partial-flushes", I think the problem is similar to >>>>>>>>>>>> https://jira.duraspace.org/browse/DS-3552: In AUTO mode >>>>>>>>>>>> <https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/FlushMode.html#MANUAL> >>>>>>>>>>>> Hibernate keeps track of all objects loaded from the database and >>>>>>>>>>>> tries to >>>>>>>>>>>> "auto-save" them in the database before executing a new query. But >>>>>>>>>>>> the more >>>>>>>>>>>> objects Hibernate loads into its session, the more objects it >>>>>>>>>>>> needs to >>>>>>>>>>>> check for modification and possible interference with the new >>>>>>>>>>>> query that is >>>>>>>>>>>> being executed. Hence the more time it takes. >>>>>>>>>>>> >>>>>>>>>>>> *@Bill and @Ying*, would it be possible for any of you to >>>>>>>>>>>> provide an anonymised and cleaned database that you can share with >>>>>>>>>>>> us? Make >>>>>>>>>>>> sure the database does not contain any sensitive information. I'm >>>>>>>>>>>> sure such >>>>>>>>>>>> a database will also be useful for other (demo and testing) >>>>>>>>>>>> purposes and >>>>>>>>>>>> the development of DSpace 7. >>>>>>>>>>>> >>>>>>>>>>>> *@Ying*, for the Collection and Community pages can you try >>>>>>>>>>>> setting the context mode to READ_ONLY in the getValidity(), >>>>>>>>>>>> addPageMeta() and addBody() methods of classes >>>>>>>>>>>> org.dspace.app.xmlui.aspect.artifactbrowser.CollectionViewer >>>>>>>>>>>> and org.dspace.app.xmlui.aspect.artifactbrowser.CommunityViewer. >>>>>>>>>>>> Here's an example of how to do that: >>>>>>>>>>>> https://github.com/DSpace/DSpace/pull/1694/files#diff-fb7249e19a6a8652860795d8fd59cd9e >>>>>>>>>>>> >>>>>>>>>>>> *@Bill*, unfortunately the class responsible for the >>>>>>>>>>>> /community-list page already uses the READ_ONLY mode ( >>>>>>>>>>>> https://github.com/dspace/DSpace/blob/dspace-6_x/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/artifactbrowser/CommunityBrowser.java#L245). >>>>>>>>>>>> But the fact that your number of (partial-)flushes is still so >>>>>>>>>>>> high, I >>>>>>>>>>>> wonder if there is still another place hibernate is loading so many >>>>>>>>>>>> objects. However as a workaround, you could enable caching of that >>>>>>>>>>>> /community-list page by setting the xmlui.community-list.cache >>>>>>>>>>>> property in >>>>>>>>>>>> dspace.cfg to true ( >>>>>>>>>>>> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L1917 >>>>>>>>>>>> ). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Tom >>>>>>>>>>>> >>>>>>>>>>>> [image: logo] Tom Desair >>>>>>>>>>>> 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 >>>>>>>>>>>> <https://maps.google.com/?q=3A,+Lucius+Gordon+Drive,+West+Henrietta,+NY+14586&entry=gmail&source=g> >>>>>>>>>>>> Gaston Geenslaan 14, Leuven 3001, Belgium >>>>>>>>>>>> <https://maps.google.com/?q=Gaston+Geenslaan+14,+Leuven+3001,+Belgium&entry=gmail&source=g> >>>>>>>>>>>> www.atmire.com >>>>>>>>>>>> <http://atmire.com/website/?q=services&utm_source=emailfooter&utm_medium=email&utm_campaign=tomdesair> >>>>>>>>>>>> >>>>>>>>>>> 2018-03-11 22:43 GMT+01:00 Kim Shepherd <k...@shepherd.nz>: >>>>>>>>>>>> >>>>>>>>>>> Hi Bill and Ying, just a note to say I haven't managed to >>>>>>>>>>>>> reproduce / investigate this problem thoroughly yet -- i keep >>>>>>>>>>>>> getting >>>>>>>>>>>>> sidetracked with other work! And I'm struggling a bit to >>>>>>>>>>>>> reproduce with >>>>>>>>>>>>> test data now that Bill is reporting the same problem with a >>>>>>>>>>>>> fairly small / >>>>>>>>>>>>> typical amount of items and bitstreams, so it's obviously not just >>>>>>>>>>>>> connected to number of bitstreams attached to a single item. >>>>>>>>>>>>> >>>>>>>>>>>>> However I still have this on my radar, and if you discover >>>>>>>>>>>>> anything else please let the list know! Once we know exactly which >>>>>>>>>>>>> conditions are needed to reproduce this / identify where things >>>>>>>>>>>>> are going >>>>>>>>>>>>> wrong, exactly, we'll log a JIRA issue so we can get a fix in for >>>>>>>>>>>>> a future >>>>>>>>>>>>> DSpace version >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers! >>>>>>>>>>>>> >>>>>>>>>>>>> Kim >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> M: k...@shepherd.nz >>>>>>>>>>>>> T: @kimshepherd >>>>>>>>>>>>> P: +6421883635 >>>>>>>>>>>>> >>>>>>>>>>>> W: www.shepherd.nz <http://shepherd.nz> >>>>>>>>>>>>> >>>>>>>>>>>>> 0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC >>>>>>>>>>>>> >>>>>>>>>>>> On 23 February 2018 at 09:33, Bill T <wil...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>> Here is my hibernate log for /community-list (page takes about >>>>>>>>>>>>>> 90 seconds to load); We have about 200 communities, 1200 >>>>>>>>>>>>>> collections, and >>>>>>>>>>>>>> 64,000 items. Unlike Ying, we essentially have one original >>>>>>>>>>>>>> bitstream per >>>>>>>>>>>>>> item, primarily pdf files. Redhat 7, Java 8, Tomcat 8.5, >>>>>>>>>>>>>> Postgresql 9.6.2; >>>>>>>>>>>>>> 32G Ram, 8 CPU This setup worked well with previous versions >>>>>>>>>>>>>> up to and >>>>>>>>>>>>>> including 5.8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not trying to pile on, but hopefully some additional info >>>>>>>>>>>>>> will be helpful! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:05,871 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 372441 nanoseconds spent acquiring 1 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 233248 nanoseconds spent preparing 3 JDBC statements; >>>>>>>>>>>>>> 482887 nanoseconds spent executing 1 JDBC statements; >>>>>>>>>>>>>> 1985778 nanoseconds spent executing 2 JDBC batches; >>>>>>>>>>>>>> 3867293 nanoseconds spent performing 3 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 29762475 nanoseconds spent executing 2 flushes (flushing >>>>>>>>>>>>>> a total of 2 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:05,873 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 0 nanoseconds spent acquiring 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent preparing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC batches; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 flushes (flushing a total >>>>>>>>>>>>>> of 0 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:16,450 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 440048 nanoseconds spent acquiring 1 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 273468 nanoseconds spent preparing 3 JDBC statements; >>>>>>>>>>>>>> 547508 nanoseconds spent executing 1 JDBC statements; >>>>>>>>>>>>>> 1702327 nanoseconds spent executing 2 JDBC batches; >>>>>>>>>>>>>> 3683682 nanoseconds spent performing 3 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 27298233 nanoseconds spent executing 2 flushes (flushing >>>>>>>>>>>>>> a total of 2 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:16,452 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 0 nanoseconds spent acquiring 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent preparing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC batches; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 flushes (flushing a total >>>>>>>>>>>>>> of 0 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:27,121 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 429299 nanoseconds spent acquiring 1 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 236026 nanoseconds spent preparing 3 JDBC statements; >>>>>>>>>>>>>> 561023 nanoseconds spent executing 1 JDBC statements; >>>>>>>>>>>>>> 1029554 nanoseconds spent executing 2 JDBC batches; >>>>>>>>>>>>>> 3446462 nanoseconds spent performing 3 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 23575938 nanoseconds spent executing 2 flushes (flushing >>>>>>>>>>>>>> a total of 2 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:27,123 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 0 nanoseconds spent acquiring 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent preparing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC batches; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 flushes (flushing a total >>>>>>>>>>>>>> of 0 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:37,220 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 2570171 nanoseconds spent acquiring 1 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 27121987 nanoseconds spent preparing 2831 JDBC statements; >>>>>>>>>>>>>> 641543786 nanoseconds spent executing 2831 JDBC >>>>>>>>>>>>>> statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC batches; >>>>>>>>>>>>>> 1108158 nanoseconds spent performing 23 L2C puts; >>>>>>>>>>>>>> 892275 nanoseconds spent performing 13 L2C hits; >>>>>>>>>>>>>> 249809 nanoseconds spent performing 28 L2C misses; >>>>>>>>>>>>>> 58195179 nanoseconds spent executing 2 flushes (flushing >>>>>>>>>>>>>> a total of 10470 entities and 24994 collections); >>>>>>>>>>>>>> 185425636 nanoseconds spent executing 17 partial-flushes >>>>>>>>>>>>>> (flushing a total of 15132 entities and 15132 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:52:37,226 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 0 nanoseconds spent acquiring 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent preparing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC batches; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 flushes (flushing a total >>>>>>>>>>>>>> of 0 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:54:36,355 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 267649 nanoseconds spent acquiring 1 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 45162338 nanoseconds spent preparing 4812 JDBC statements; >>>>>>>>>>>>>> 1756479486 nanoseconds spent executing 4812 JDBC >>>>>>>>>>>>>> statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC batches; >>>>>>>>>>>>>> 36704624 nanoseconds spent performing 1411 L2C puts; >>>>>>>>>>>>>> 50803773 nanoseconds spent performing 5623 L2C hits; >>>>>>>>>>>>>> 14742351 nanoseconds spent performing 11243 L2C misses; >>>>>>>>>>>>>> 31181919 nanoseconds spent executing 2 flushes (flushing >>>>>>>>>>>>>> a total of 13504 entities and 25940 collections); >>>>>>>>>>>>>> 60069213452 nanoseconds spent executing 7045 >>>>>>>>>>>>>> partial-flushes (flushing a total of 37986752 entities and >>>>>>>>>>>>>> 37986752 >>>>>>>>>>>>>> collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2018-02-22 13:54:36,358 INFO >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.hibernate.engine.internal.StatisticalLoggingSessionEventListener >>>>>>>>>>>>>> @ >>>>>>>>>>>>>> Session Metrics { >>>>>>>>>>>>>> 0 nanoseconds spent acquiring 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent releasing 0 JDBC connections; >>>>>>>>>>>>>> 0 nanoseconds spent preparing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC statements; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 JDBC batches; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C puts; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C hits; >>>>>>>>>>>>>> 0 nanoseconds spent performing 0 L2C misses; >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 flushes (flushing a total >>>>>>>>>>>>>> of 0 entities and 0 collections); >>>>>>>>>>>>>> 0 nanoseconds spent executing 0 partial-flushes (flushing >>>>>>>>>>>>>> a total of 0 entities and 0 collections) >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> You received this message because you are subscribed to a >>>>>>>>>>>>>> topic in the Google Groups "DSpace Technical Support" group. >>>>>>>>>>>>>> To unsubscribe from this topic, visit >>>>>>>>>>>>>> https://groups.google.com/d/topic/dspace-tech/VIofW7EwEXY/unsubscribe >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>> To unsubscribe from this group and all its topics, send an >>>>>>>>>>>>>> email to dspace-tech...@googlegroups.com. >>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>> dspac...@googlegroups.com. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Visit this group at >>>>>>>>>>>>>> https://groups.google.com/group/dspace-tech. >>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google Groups "DSpace Technical Support" group. >>>>>>>>>>>>> >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>> it, send an email to dspace-tech...@googlegroups.com. >>>>>>>>>>>>> To post to this group, send email to dspac...@googlegroups.com >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Visit this group at >>>>>>>>>>>>> https://groups.google.com/group/dspace-tech. >>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to a topic >>>>>>>>>>>> in the Google Groups "DSpace Technical Support" group. >>>>>>>>>>>> To unsubscribe from this topic, visit >>>>>>>>>>>> https://groups.google.com/d/topic/dspace-tech/VIofW7EwEXY/unsubscribe >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> To unsubscribe from this group and all its topics, send an email >>>>>>>>>>>> to dspace-tech...@googlegroups.com. >>>>>>>>>>>> To post to this group, send email to dspac...@googlegroups.com. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Visit this group at https://groups.google.com/group/dspace-tech >>>>>>>>>>>> . >>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "DSpace Technical Support" group. >>>>>>>>>>> >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>>> send an email to dspace-tech...@googlegroups.com. >>>>>>>>>>> To post to this group, send email to dspac...@googlegroups.com. >>>>>>>>>>> >>>>>>>>>> < >>>>>>>>>> >>>>>>>>> -- > All messages to this mailing list should adhere to the DuraSpace Code of > Conduct: https://duraspace.org/about/policies/code-of-conduct/ > --- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dspace-tech+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-tech@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
