My gut feeling (given the large amount of transitory Errors instances) is the application is doing a lot of lookups involving just-in-time bindings, maybe also involving child injectors.
When Guice attempts a just-in-time binding it keeps track of any errors - when the uppermost binding fails the injector cleans up any intermediate stray bindings and throws the aggregate Errors instance. If I can get some spare time this weekend I'll try a frequency analysis of the Errors in that heap dump, this should indicate what bindings have the most effect and whether child injectors are involved. On 15 Aug 2012, at 22:30, Brian Pontarelli wrote: > I thought I would share some information I've been collecting while profiling > CleanSpeak. Just a quick run down on CleanSpeak to set the stage: > > Written entirely in Java > Uses Prime MVC > The test we setup was to our main WebService entry point > This test simulates handling real-time chat inside games > This is usually between 1,000-30,000 messages per second depending on the game > CleanSpeak is currently able to handle 4,000-10,000 messages per second on a > single server (we are working to get that higher though) > Using a custom built load test system to simulate 10-100 clients hitting the > WebService > Using NetBeans profiler for timing metrics > > Based on the time profiling information we are getting from NetBeans, here > are the top classes and the percentage of the processing time that they > consume (full disclosure - I remove 3 of our classes from this list): > > com.google.inject.multibindings.MapBinder$RealMapBinder$2.get() > 6.557378% > com.google.inject.internal.InternalContext.getConstructionContext(Object) > 3.3661668% > com.google.inject.internal.Errors.withSource(Object) 3.2637234% > freemarker.core.Environment.process() 2.9239252% > com.google.inject.internal.InjectorImpl$4.get() 2.7241063% > com.google.inject.internal.ConstructorInjector.construct(com.google.inject.internal.Errors, > com.google.inject.internal.InternalContext, Class, boolean) 2.472883% > org.primeframework.mvc.parameter.el.DefaultExpressionEvaluator.getValue(String, > Object) 2.457187% > org.primeframework.mvc.parameter.el.ExpressionException.<init>(String) > 2.3623912% > com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(Object[]) > 2.3241668% > org.primeframework.mvc.workflow.RequestBodyWorkflow.perform(org.primeframework.mvc.workflow.WorkflowChain) > 2.286451% > org.primeframework.mvc.servlet.ServletObjectsHolder.getServletRequest() > 2.0882587% > org.primeframework.mvc.parameter.el.MemberAccessor.getAnnotation(Class) > 2.08238%3077 > > I left off everything below 2% use. The interesting things I've found here > are that Multibindings appears to be quite expensive. I'm going to try and > remove that use to see if I can get back that 6%. I also found that Error > object that I wrote about in a previous post near the top at 3.26%. This > seems to be quite expensive for an Error object, specifically when Guice > errors are almost always found and fixed at test time and not in production. > > Has anyone else seen these types of performance results and have good insight > into helping reduce them? > > -bp > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
