Hi, This discussion interests me. One point that you seem to entirely omit in your description is the number (and size) of XML documents you intend to have in there... otherwise, there's nothing that prevents you to load it all in ram...
Paul On Mardi, avril 16, 2002, at 10:29 , Robert Koberg wrote: > Hi, > > I starting to investigate content XML storage options for an > application that is driven by java servlets and XSLT. There are so many > options ranging from free (Xindice) to very expensive (Tamino). > I currently have an app based on filesystem XML documents. The content > XML could be changed anytime a user is using the app (based on a lock > system). The way the app is built would map nicely to an XML DB (I > believe...). > > I am in the process of learning how to do stress/load testing. I was > hoping you guys could help on a few (not so simple) things: > [Example system info: RAM=512MB, processor=800mHz_XEON, > OS=Linux_RedHat, webserver=Apache, servlet-container=(Resin | Tomcat)] > [Each HTTP request would require a cached XSLT Template and between 1 > and 5(n?) filesystem XML documents] > > 1) Is there a general rule of thumb when the number of concurrent hits > to a filesystem based app would hit the wall? > 2) What are people's impressions of native XML DBs? Who is the best? > Who is the best for a small budget (hopefully much less than 25k)? > 3) If you have a user base on a single server of between 2 to 20 users > would you need an XML DB or would a filesystem based app work decently? > 4) If you have a user base of 'n' number of groups of 2-20 users, what > would 'n' need to equal before you hit the wall? > 5) Are there any suggestions on how to test these types of things? (I > recently bought _Java Tools for eXtrmeme Programming_ , by Richard > Hightower and Nicholas Lesiecki, which will hopefully help me going > forward). > > Thanks is advance for any help! > -Rob > > > > > --------------------------------------------------------------------- > In case of troubles, e-mail: [EMAIL PROTECTED] > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
