Hi Tom, Thanks for this extra level of information - it will really help.
A few random questions come to mind: > d. Separate servers for webapp, DB, storage and ancillary functions > Webapp/DB servers are HT 8-core Intel servers running Ubuntu Linux > with 16GB of memory and fast local storage > Java memory: -Xmx2048M -Xms2048M Is there a reason why you only allocate 1/8th of the system memory to the application? Have you found that adding extra doesn't help? > - Assetstore: random structure causes large overhead on filesystem for no > real gain Are you able to expand on the overhead that is caused, and from your profiling, explain how the structure could be improved? My gut (and uniformed) instinct would be that since asset store reads are completely random depending on the items being viewed at the time, the layout of directories would be irrelevant. Writes may be slightly less efficient, but since writes only tend to occur once, they are of less consequence. > - Search indexer: fails on large repositories, slowing down and eventually > running out of memory. Do you have any percentages on the amount of page views that relate to browse, and how many relate to other views? I'm curious if browse from the front end is causing an issue too? The reason I'm asking, is that with the potential inclusion of the dspace-discovery layer in a future version, this could replace the database-driven browse system with solr. Not only will this provide a richer faceted search, but it could likely offer a good performance boost for browse-related functions. It also offers another way of scaling-out, by putting solr on a different server. > 4. We can't commit to volunteering unless this can be incorporated into the > work we need to undertake in our primary capacity of running the University's > Institutional Repository. However, we would be willing to try and make this > happen. That would be great if you could, and we'd all really appreciate your input. Users of the software such as yourself, or BioMed Central's Open Repository are pushing the software in ways that 95% of installations don't (yet). In order to push past these boundaries in terms of scalability the only way we can effectively do so is with the active participation of those who are encountering the problems. One of the joys of working in an open source environment is that we have the structures and process that enable this, and it is great to watch the results when everyone pitches in together to improve the software for us all. Cheers, Stuart Lewis IT Innovations Analyst and Developer Te Tumu Herenga The University of Auckland Library Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand Ph: +64 (0)9 373 7599 x81928 ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
