I'm not exactly sure what you expect from the figures that other people provide?
Maybe I tell you we once stresstested a Struts/OJB based system with 200 concurrent users firing requests and a sub-second average response time.
It was a Tandem Nonstop system with 2 300 Mhz CPU, each equipped with 512MB of Ram. We used the Tandem Nonstop SQL database.
This test was helpful for our project, because we got clear figures about our then target environment.
But how can such figures be of any help for you? I don't expect that you are running on an environment as exotic as Tandem Nonstop Server :-)
By running a Struts/OJB based applications on clustered J2EE Server you will be able to achieve *any* request per minute rate that you want to see. Just add more machines into the cluster.
This is possible because J2EE container provide the infrastructure for scalibility and frameworks like STruts and OJB are carefully designed for scalability and not to produce any bottlenecks.
So IMO the real question is: how much throughput do you need? And how must your system be sized to give you this throughput.
This depends on *many* factors, and OJB is only one of them.
So IMO you have to perform such a test on your own!
DId you execute our perfoemance testsuite against your target system already? This tool will give you a first impression how OJB APIs compare to native JDBC programming.
Aaron Longwell wrote:
Jason,
Thanks for the feedback. I understand you're probably killing these servers doing this intense processing... but what about # users? Is it one guy running intense simulations... I'm curious about # requests per minute type of loads.
Thanks, Aaron
Jason McKerr wrote:
I've also worked with OJB on high-load situations in J2EE environments. We're using JRun and/or Orion with OJB in a clustered/distributed
environment. This is a National Science Foundation project called the
Network for Earthquake Engineering Simulation (NEES). The only major problem that we ran into was the cache. JCS just isn't
good, and hasn't seemed to get much better over the last year. We ended
up plugging in Tangosol's Coherence Clustered Cache into the system. We
can also do write-behinds, and buffered data caching that is queued for
transaction. That's important to us because we're dealing with very
expensive scientific data that _can't_ get lost if a db goes down. Some
of these Tsunami experiments can get pretty expensive.
Otherwise, we use mostly the PersistenceBroker, and a little of the ODMG. Performance seems better on PB, but less functional. It's not really that much of a problem anyway, because we can cheaply and quickly add app-servers to the cluster.
Jason
On Thu, 2003-06-12 at 22:14, Aaron Longwell wrote:
I realize I may be comparing Apples to Enterprise Applications here, but I'd like to hear some feedback about using OJB in high-load (load balanced?) environments.
On an OJB web application, how many requests have you seen an application handle? Would anyone be concerned about using OJB on an enormous e-commerce site? (EBay, Amazon, etc)?
Thanks for the input, Aaron
---------------------------------------------------------------------
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]
