Two things: 1. We should also consider caching the Jacob state. Instead of always serializing / writing and reading / deserializing, caching those states could save us a lot of reads.
2. Cutting down the transaction count is a significant refactoring so I would start a new branch for that (maybe ODE 2.0?). And we're going to need a lot of tests to chase regressions :) I think 1 could go without a branch. It's not trivial but I don't think it would take more than a couple of weeks (I would have to get deeper into the code to give a better evaluation). On 6/6/07, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Howza, I started testing a short-lived process implementing a single request-response operation. The process structure is as follows: -Receive Purchase Order -Do some assignments (schema mappings) -Invoke CRM system to record the new PO -Do more assignments (schema mappings) -Invoke ERP system to record a new work order -Send back an acknowledgment Some deployment notes: -All WS operations are SOAP/HTTP -The process is deployed as "in-memory" -The CRM and ERP systems are mocked as Axis2 services (as dumb as can be to avoid bottlenecks) After fixing a few minor issues (to handle the load), and fixing a few obvious code inefficiencies which gave us roughly a 20% gain, we are now near-100% CPU utilization. (I'm testing on my dual-core system) As it stands, Ode clocks about 70 transactions per second. Is this good? I'd say there's room for improvement. Based on previous work in the field, I estimate we could get up to 300-400 transactions/second. How do we improve this? Well, looking at the end-to-end execution of the process, I counted 4 thread-switches and 4 JTA transactions. Those are not really necessary, if you ask me. I think significant improvements could be made if we could run this process straight-through, meaning in a single thread and a single transaction. (Not to mention it would make things easier to monitor and measure ;) Also, to give you an idea, the top 3 areas where we spend most of our CPU today are: 1) Serialization/deserialization of the Jacob state (I'm evaluating about 40-50%) 2) XML marshaling/unmarshaling (About 10-20%) 3) XML processing: XPath evaluation + assignments (About 10-20%) (The rest would be about 20%; I need to load up JProbe or DTrace to provide more accurate measurements. My current estimates are a mix of non-scientific statistical sampling of thread dumps and a quick run with the JVM's built-in profiler) So my general question is... how do we get started on the single thread + single transaction refactoring? Anybody already gave some thoughts to this? Are there any pending design issues before we start? How do we work on this without disrupting other parts of the system? Do we start a new branch? alex
