Vincent Massol wrote: > Thanks all for your performance tips ! :-) > I do really appreciate your help. > > I haven't mentioned it my previous emails but the application is already > written (the first version which is almost the one that will be > released) and has already been tested in a lab using big hardware. > > We wanted to verify early that we could achieve the result ... and it > worked ! We have sized the memory so that we never have full GC that > takes 5 seconds (our GC take max. 20 ms if I remember correctly). We are > doing roughly 25 TPS (about 10-15 SQL queries for each request - we have > reduced it to the minimum -, 20% write and 80% read) on a Sun 450 Mhz, > on 1 CPU (we are using 4 way CPUs and have bound each weblogic instance > to a given CPU - 3 CPUs are bound to 3 WL instance and the last one is > for the OS - We have tried all combinations possible and that was the > best for our applications) => we're doing 75 TPS on a 4 way CPU box. > This within the 99.97% response time < 1s. And consistently (we left the > test running during full nights) ... :-)
Impressive. Now, how close to 1s are you? > Now, as I said, the application is not completely finished and we're > using more and more Avalon components (whereas in the tested version we > were only using a few for technical services - we are now using Avalon > component for business services). Thus my worries about the > synchronization stuff. Again, if you have mostly ThreadSafe components, you are going to see the least impact. That is the approach for Phoenix blocks and it works well. > I agree with all you have said. However, my biggest fear (and you have > not yet convinced me !) is that even though synchronization is fast it > will still block *all* threads during that time. Object creation may > take a bit longer but they won't block any other thread. So I'm more > worried about synchronization. No, that is not an accurate statement. It only blocks threads that are *contending* for the same resource. The BucketMap reduces the chance of thread *contention* to very little. (I would always make sure the bucket size of the map is more than the threads used to process transactions 255 is a good number--and the default). If you have 100 threads all accessing the same BucketMap, it will not cause any one thread to block unless they are both going for the same bucket. Because I have observed that if the number of buckets is a power of two, I caused the constructor to never allow that to happen. As it is now, we have a nicely dispersed system so that the number of threads contending for the same resource is very low. But the statement saying it will block *all* threads on access is flat out wrong. It will only block threads that access the same bucket. If you want to ease your mind, you can build a quick test program that creates 1000 objects, and perform the same hash algorithm for the BucketMap on those objects. The hash algorithm is this: object.hashcode() % m_numBuckets; The default number of buckets is 255. Hopefully you will see only a few buckets used a little more than the others. The bucket level is where thread contention can happen. You should not see unnecessary thread contention. > WRT to the ComponentHandler being created at runtime, it won't happen > for us as we define all our components in the ECM config file. > > Does anyone know if a dispose-less CM implementation with no > synchronization exist somewhere ? DefaultComponentManager in Framework--but it has no support for anything but ThreadSafe components. ---------------------------------------------------- Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinum&refcd=PT97 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
