On 22 July 2010 13:11, Karsten Gaul <[email protected]> wrote: > >> I don't know how to administer Oracle dbs > > me neither...
But presumably the db admins should be able to sort this out? >> Surely there must be ways to configure the DB so that it remains >> active even under heavy load? >> >> Or at least it should degrade gracefully. > > That's what I hoped for. Maybe the responses take some more time because the > db blocks incoming requests until it's finished but it seems to consume all > the memory until it recognizes that this wasn't the best idea. > Unfortunately, at this point it's already too late. That sounds like a configuration problem. For example too many connections allowed for the memory available. > Thanks anyway. I had hope that it was my fault because my test plan is badly > configured. As your test plan is calling the database via the web application, in theory enough users of the application can cause the same problem. You have proved that the web application can bring down the database (which is useful to know). Whether it is possible for this to occur when not using JMeter depends on how close the test plan load is to what the application is intended to support. Use application logs to gather stats on the page requests made by actual users, and compare those with the load generated by JMeter. Adjust the JMeter test plan as necessary to reflect the target load. You also need to look at the web application to see if some of the SQL can be changed to reduce the database load. >> For example, limiting the number of active connections, limiting >> resources that can be used by a single connection. >> >> That might also give a better clue as to which queries are causing the >> problem. > > > rgds > Karsten > > --------------------------------------------------------------------- > 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]
