Cory, Comments below:
On 04/18/2007 01:54 PM, Cory Snavely wrote: > Well, as I said at first, it all depends on your definition of what a > memory hog is. Today's hog fits in tomorrow's pocket. We better all > already be used to that. Thank you for proving my point on memory bloat pervasiveness in the IT industry. This type of thinking allows vendors (whether open source or proprietary) to drive up the "base" systems requirements without greatly improving functionality because it is predestined. > Also, I don't think for a *minute* that the original developers of > DSpace made a casual choice about their development environment--in > fact, I think they made a responsible choice given the alternatives. > Let's give our colleagues credit that's due. Their choice permits > scaling and fits well for an open-source project. Putting the general > problem of memory bloat in their laps seems pretty angsty to me. > > Lastly, dedicating a server to DSpace is a choice, not a necessity. We > as implementors have complete freedom to separate out the database and > storage tiers, and mechanisms exist for scaling Tomcat horizontally as > well. In the other direction, I suspect people are running DSpace on > VMware or xen virtual machines, too. I didn't say they made a casual choice about their development environment. I said the functional requirements of the application didn't justify the memory footprint required to run this application. Whether or not they made a choice that "fits well for an open-source project" depends on your definition of Open Source. However, I don't think that debate is relevant to this discussion. As far as scaling requirements, it depends on where you want scalability. As you pointed out, there is a natural ability with web applications to scale them vertically through hardware or Tomcat's, now native, horizontal approach. Since either approach needs hardware, the memory footprint of an application needs to be taken into account. The higher the "base" system requirements, the likelihood of someone having a scalable system is lowered due to total cost of ownership (TCO). While virtual machine technology can help lower some TCO issues, it brings in a whole new batch of problems which are out of scope for this discussion. The general problem of memory bloat rests in all developers laps (mine included). As an industry, we need to constantly weigh our use of memory against the functionality we are providing. The functionality provided by Dspace isn't rocket science, and shouldn't require memory footprints greater than most of systems that get people into space. -- Brad Teale Web Application Developer Digital Library Development Lab University of Minnesota Libraries [EMAIL PROTECTED] > On Wed, 2007-04-18 at 13:40 -0500, Brad Teale wrote: >> Pan, >> >> Dspace is a memory hog considering the functionality the application >> provides. This is mainly due to the technological choices made by the >> founders of the Dspace project, and not the functional requirements the >> Dspace project fulfills. >> >> Application and memory bloat are pervasive in the IT industry. Each >> individual organization should look at their requirements whether they >> are hardware, software or both. Having to dedicate a machine to an >> application, especially a relatively simple application like Dspace, is >> wasteful for hardware resources and people resources. >> >> Web applications should _not_ need 2G of memory to "run comfortably". >> ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
