Hi all, I'm sorry if any of you have felt that this issue is not being taken seriously in the past. The reality of the situation is that we (the DSpace Developers/Committers) currently depend on feedback/testing from larger DSpace instances around these sorts of scalability and memory issues. As DSpace is Community Built & Supported Software, there are a couple things to keep in mind:
(1) DSpace software has zero full-time developers. All Committers are volunteers and can only devote as much time as their individual institutions allow. Although I officially have "DSpace" in my title, I also wear several hats in DuraSpace. Therefore, even I don't have much time in a given week to devote towards actual DSpace development work. (2) We currently don't have a centralized server with enough test data to run many of these memory or scalability tests on our own. I think this is something we could look into improving upon (especially if anyone has test data to donate to the cause). I agree with Robin T. that it is in everyone's interest to improve our performance testing prior to each release. I'd also encourage Graham (and others) to share their testing routes so that we can work to make this happen, and start to locate these performance issues *before* new releases, rather than after. I'm also very happy to see these issues starting to gain some leverage. The reality of the situation is that we need one or more volunteers to step up and help to make these improvements or suggest testing routes that can allow us to better investigate where memory leaks may be occurring (or point them out if you've already found where the leaks are). All of us want DSpace to scale well and avoid memory leaks -- if it takes a new architecture to do so that is one possible route forward. But, the main thing to keep in mind is that DSpace is built & maintained by volunteer developers -- so, we need to find the volunteers (and convince their institutions) to help make this happen. It sounds like we've already located a few interested parties in this discussion. So, I hope that we can move forward with this work soon and perhaps even make some quick improvements in time for the rapidly approaching 1.7.0 release. If you'd like to volunteer to help us out, please let us know how you'd like to help! - Tim -- Tim Donohue Technical Lead for DSpace Project DuraSpace.org On 9/22/2010 10:33 AM, Tom De Mulder wrote: > > I am very happy to see that this issue seems finally to be taken seriously. > However, I find myself getting a bit frustrated that it was never taken > seriously when I raised it in the past. > > I think the DSpace source code carries with it a lot of historical baggage, > and it could do with being addressed even without making fundamental changes > to the basic architecture. Although my personal favourite would be a > completely new architecture with more loosely coupled modules, but fixing > memory leaks and the associated slow performance would be a good start. > > I can add that, for example, deleting a collection with 1200 items on our > rather powerful DSpace machines will take two hours, and uses most of the > available memory. You can see why I would like that no longer to be the case. > > > Best regards, > > -- > Tom De Mulder<[email protected]> - Cambridge University Computing Service > +44 1223 3 31843 - New Museums Site, Pembroke Street, Cambridge CB2 3QH > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
