I splt the rows up. But if you're planning on working with a million rows per client per year.. yeah offline processing would probably be best.
My webgate app does realtime processing of television programming to create an online TV grid.. and thats still only about 20,000 records. But even live processing of that is pretty fast (using MySQL). - Brent On Mon, 5 Jul 2004 23:45:29 +0200, Yves Vindevogel <[EMAIL PROTECTED]> wrote: > do you serve 7000 rows in a page, or does your query return 7000 rows > that you split up ? > my database will be around .... euh, 1 million records per client per > year (target: 100 clients) > (that's why i want to do off line storage) > > > > On 05 Jul 2004, at 17:51, Brent Johnson wrote: > > > I'm running similar amounts of load in production for an intranet site > > I did that runs Cocoon 2.1.4 - about to be upgraded to 2.1.5. It's > > only accessible by certain individuals (around 50 or so.. but usually > > never sees more than 10-20 at a time). > > > > I've had no reports of any site problems. We arent steadily crunching > > on XML files that are 30K. We have some pretty decent sized requests > > though (processing of about 7000 database records if you choose the > > right type of medical treatment search). > > > > Anyways - my recommendation would to check out this thread or similar > > ones from the mailing list: > > > > http://marc.theaimsgroup.com/?t=107836170600001&r=1&w=2 > > > > I found this helpful for getting the site running a little faster and > > more stable. We were having these nasty problems where Cocoon starts > > serving BLANK pages (yes its serving a page.. its just completely > > blank). We found increaing pool sizes and the heapsize fixed. > > > > The server we have in production is a single Dell Poweredge.. its a > > 2.4Ghz Xeon I think, with a gig of ram and about 80G drive space > > running Redhat Linux (soon to be upgraded to another distro). > > > > - Brent > > > > On Mon, 5 Jul 2004 11:21:35 +0200, Yves Vindevogel > > <[EMAIL PROTECTED]> wrote: > >> Well, we would start out with one server (the DL described) > >> When the app is succesful for my client, the second server can be > >> bought. > >> That would immediatly split up webserver and database server > >> > >> Users: 10 simultaniously running pages of 30K. That's a strict > >> minimum. > >> But that should never give a problem, right > >> > >> The DB is not an issue. I will build XML files from the tables on > >> regular bases. > >> So, reports and such (which is 90% of the app) are coming from xml and > >> not from db. > >> > >> > >> > >> > >> On 05 Jul 2004, at 11:00, Antonio Gallardo wrote: > >> > >>> Yves Vindevogel dijo: > >>>> I can run on space ship on slackware with 1 mb ;-)) > >>>> > >>>> Problem is that I need to make the bid before the application. > >>>> So any hints would be nice. > >>>> > >>>> So you would go for more RAM in the machine right away ? > >>> > >>> For sure 1 Megabyte will not be enough to run tomcat + linux. We made > >>> some > >>> tests last year in a PII 266 MHz with 96 MB and that was very slow! > >>> We > >>> needed to wait some minuts to get the servlet container running..... > >>> I > >>> think that 1 MB is a total crazy bet. ;-) > >>> > >>> Seriously, We have systems running nice on 512 MB and no problems at > >>> all. > >>> 1 GB is better (we use 1 GB for the development server) and 2 GB even > >>> better. I never used a 2 GB config for a cocoon application, but this > >>> is > >>> my own case, your needs can be diferents. It depends on various > >>> factors > >>> as: > >>> > >>> 1- How many users are you targetting. > >>> 2- DB size > >>> > >>> The idea is to distribute the RAM between Cocoon and the database to > >>> get > >>> the best performance. > >>> > >>> Best Regards, > >>> > >>> Antonio Gallardo > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
