OK, I did some testing: from a client (not in-VM) on the same host, calling 100x findAll which returns 1000 EB from an In-Memory BMP.
I implemented different solutions: 1) I preload the chain and reuse it 2) I preload the chain and if one of the interceptors is marked as "stateless="false"" I dynamically add a new interceptor in front of the chain that contains a copy of the chain (in a MO) 3) I preload the whole chain and store it in a MO and I have a new ClientContainer implementation that do not take an Interceptor as parameter but an MO that contains the chain Time on my machines were something like: - default (no optimisation): 11 seconds - opt 1): 8 second - opt 2): 7-8 second - opt 3): 22 seconds!!! I don't understand why!!! For opt 3, may the problem is related to the fact that in the marshalled collection that is returned from findAll, all proxies do share the same chain, which is very good (bandwith!) for case 1 and 2 but maybe in case 3, as the content is inside a MO, each proxy will get its own byte[]. Don't know, just a quick 10'000 feet analysis. Implementation 2 is cool because it can work easily locally and remotly for stateless and stateful chains. I am pretty sure the number would be better if the client and server would be running on different hosts (because in my case, the total amount of client+server serialization was all on the same machine while with the optimisations, the server work is quite reduced). So, is 4 seconds out of 11 (35%) a sufficient improvment so that I commit the new files? Modifications are: - ProxyFactory updated - MarshallerInterceptor added N.B.: the "tests-unit" testsuite module target runs correctly with these modifications > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Scott M Stark > Envoyé : samedi, 11 janvier 2003 10:51 > À : Jboss-Dev > Objet : [JBoss-dev] Re: Optimisation for proxy creation? > > > Sure, this is something to try out to see how much of an improvement can > be made. Start with entities as these are the most likely to be created > frequently. I really doubt session proxy creation can be a hotspot as its > just not a frequent event in a normal workflow. > > As for sharing interceptors, its a question of whether or not > they have state. None > currently do, but they could, for example an encryption key. We would have > to have an attribute that defines whether the interceptor is > stateless and if the > entire stack for a container is stateless, it can be reused. > Otherwise it has to > be copied. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > From: "Sacha Labourey" <[EMAIL PROTECTED]> > To: "Jboss-Dev" <[EMAIL PROTECTED]> > Cc: "Scott M Stark" <[EMAIL PROTECTED]>; "Bill Burke" > <[EMAIL PROTECTED]> > Sent: Saturday, January 11, 2003 1:12 AM > Subject: Optimisation for proxy creation? > > > > Hello, > > > > While digging in ProxyFactory (Branch_3_0) to solve some clustering > > issues/optimisations, I thought about the current proxy > creation and maybe > > we should do something here: I think it is a hotspot. > > > > In getStatefulSessionEJBObject and getEntityEJBObject, each time we must > > return a proxy, we: > > 1 - create a context object > > 2 - assign some id, invoker, etc. to the context > > 3 - create a ClientContainer that holds the context > > 4 - load the interceptor chain and assigne the ClientContainer > as the first > > element of the chain > > 5 - create a java proxy that holds the chain (i.e. the ClientContainer) > > > > Elements 1, 2, 3 and 5 could be ok in term of performance. > Element 4 is not > > cheap. Loading the chain will iterate over the interceptor classes and > > create a new instance of the class and build the chain. > > > > Now we have two cases: > > A - it is a remote call > > B - it is a local call > > > > If it is a remote call, it first mean that we could cache this > chain because > > it will be serialized (copied) anyway. But the next question > is: what really > > changes between proxies? Only the Context (that holds the identity). > > Consequently, wouldn't be much more efficient (for remote call) to > > pre-marshall everything except the ClientContainer and the > context so that > > when returning a proxy, we only have to serialize these two > objects and not > > the whole thing. We would have: > > > > Java Proxy <=> ProxyHandler-ClientContainer <=> Marshalled > > chain+invoker+... > > |--> Context > > > > When the proxy is unmarshalled on the remote side, the ClientContainer > > starts by unmarshalling the chain (as the RMI subsystem do it > currently) and > > complete the chain. > > > > If it is a local call, then the chain generation is ok as we use a > > pass-value semantic and each proxy must have its own copy of the chain. > > Question 1 (for local calls!): could we share *on the server* this chain > > between proxies of the *same* EJB. If that's the case, then it > means that we > > wouldn't need to re-create this chain everytime. > > > > Now, I've only spoken about getStatefulSessionEJBObject and > > getEntityEJBObject. But now think about getEntityCollection! Its > > implementation does exactly that N times! => in CMP when you return a > > collection in-VM (by-reference) of, let's say 100 elements, we not only > > create 100 proxies, but we also create 4x100 interceptors > instances that we > > plug together. > > > > Now imagine that our client-side interceptors can be shared for > all proxies > > of the same EJB type (on the server). In this case, we would > still have to > > build 100 proxies, but no interceptors at all: we would just have all > > ClientContainers target the same chain of interceptors. > > > > Conclusion, we should look at: > > - minimizing serialization work for remote calls > > - minimizing object creation for local calls > > > > Am I lost on the moon? > > > > Cheers, > > > > > > > > Sacha > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
