Hi, Bram. Yes, I think this is an important topic. We are running a rather advanced, optimized stack on fast hardware, but DSpace is still slow enough that my editors complain fairly often. I don't have any hard numbers, but someone should really do some proper benchmarking (ie, benchmark from two separate machines, where the client is more powerful than the server, with some multi-threaded test tool like vegeta).
For reference, our production DSpace (5.5, XMLUI) is running on a Linode VPS with twenty-four GB of RAM, SSD storage, and eight CPUs! PostgreSQL is using 10% of system RAM for buffers, Tomcat JVM heap is using a six GB heap but with plenty to spare, and the rest of system RAM is used for Solr indexes. Our software stack is nginx→Tomcat, but even if you circumvent nginx and go straight to Tomcat it's the same. We basically have zero resource contention/bottlenecks. You should see our system graphs: CPU usage is like 100–200% out of 800% (eight CPUs) and RAM usage is 75% allocated to buffers, which Linux does just because the RAM isn't being used by any applications! Single-threaded indexing performance is the next topic, since repository sizes are growing and this is becoming a nuisance! I could be involved in this, it is very interesting to me. Thanks! On Sat, Feb 18, 2017 at 1:34 PM emilio lorenzo <[email protected]> wrote: > Hi, > > My vote, It is a relevant issue > > Best > > Emilio > > > El 18/02/2017 a las 11:46, Bram Luyten escribió: > > Hi, > > apologies for cross posting but though this would be of interest to the > different lists. > > Because this could be a relatively technical topic, I wanted to see if > there's an interest to dedicate one of the next DCAT calls to DSpace > performance: > > - are your pages loading fast enough? > - are you suffering from downtime and how are you dealing with this? > - which performance related JIRA tickets are out there and should we raise > attention to them? > - Show & tell of approaches, for example, > https://wiki.duraspace.org/display/~terrywbrady/Using+New+Relic+to+Monitor+XMLUI > <https://wiki.duraspace.org/display/%7Eterrywbrady/Using+New+Relic+to+Monitor+XMLUI> > > What do you think? Too technical? Relevant? Should we schedule it? > > cheers, > > Bram > > [image: logo] Bram Luyten > 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 > Esperantolaan 4, Heverlee 3001, Belgium > atmire.com > <http://atmire.com/website/?q=services&utm_source=emailfooter&utm_medium=email&utm_campaign=braml> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Alan Orth [email protected] https://englishbulgaria.net https://alaninkenya.org https://mjanja.ch -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
