are you load testing wicket in development mode? -igor
On Sun, Feb 8, 2009 at 8:32 PM, Martin Makundi <[email protected]> wrote: >> that means you can create about 3500/second...how many users do you >> have on that server? > > It's just a load test. It's a heavyish page on itself and I am hitting > it with about 20 concurrent users. > >> btw, your memory profile attachment didnt make it through, >> maybe you can upload your images somewhere else. > > Yeah, I noticed. Here: http://s5.tinypic.com/2igki7k.jpg > > Note, the allocation count is wild. It is inconsistent with the > invocation count: > >> can you show us the timing screenshot, i am very curious. > > Here: http://s5.tinypic.com/2yoviuf.jpg > > I am curious about the bug I mentioned in suggestion 2), it appears > like a blatant oversight bug, don't you think? > > ** > Martin > >> On Sun, Feb 8, 2009 at 8:09 PM, Martin Makundi >> <[email protected]> wrote: >>> Micro -> multiplied under load so the cost accumulates. And here >>> attached is a picture of the memory profile, I am not sure if I read >>> this right, but it says 6-8 Mb. >>> >>> ** >>> Martin >>> >>> 2009/2/9 Igor Vaynberg <[email protected]>: >>>> is that 291 milliseconds or 291 microseconds? >>>> >>>> -igor >>>> >>>> On Sun, Feb 8, 2009 at 7:46 PM, Martin Makundi >>>> <[email protected]> wrote: >>>>> I remembered it was a hotspot. Checking again, it is not a memory >>>>> bottleneck but a performance bottleneck. I apologise for my >>>>> imprecision. >>>>> >>>>> I have several BigDecimalLabels each with its own converter. Each >>>>> instance creation takes 291 us on the reference computer. Furthermore, >>>>> each of the getNumberFormat -call takes 215 us each. >>>>> >>>>> This seems insignificant at first, but in load tests it becomes >>>>> significant (top-2 and top-3 hoggers). >>>>> >>>>> Two suggestions: >>>>> 1. >>>>> I wonder if, instead of cloning the NumberFormats for every use, a >>>>> lazy threadlocal copy should be used instead? >>>>> >>>>> 2. >>>>> Another thing that came into my mind is, that there is >>>>> newNumberFormat(Locale locale) -method in AbstractDecimalConverter, >>>>> but the method is never used [instead, there is a direct "numberFormat >>>>> = NumberFormat.getInstance(locale);" -invocation in >>>>> getNumberFormat(Locale locale)]. >>>>> >>>>> Is this not a bug? >>>>> >>>>> I would like to override the newNumberFormat method (if it was ever >>>>> actually used) in my own XXConverter, in order to parametrize it for >>>>> my specific style. >>>>> >>>>> ::: >>>>> >>>>> As what comes to the >>>>> org.apache.wicket.Component#getConverter(java.lang.Class), I guess I >>>>> will have to implement my own TunedConverterLocator that can >>>>> orchestrate the desired converer variants for each type. >>>>> >>>>> ** >>>>> Martin >>>>> >>>>> 2009/2/8 Jeremy Thomerson <[email protected]>: >>>>>> What in particular was hogging that 200MB of memory? Was your converter >>>>>> holding something? If it were just a simple converter class like most, >>>>>> it >>>>>> would take thousands upon thousands of them to take that much memory. >>>>>> Most >>>>>> likely, you have another issue. Run a profiler and let us know what's >>>>>> using >>>>>> the memory. >>>>>> >>>>>> >>>>>> -- >>>>>> Jeremy Thomerson >>>>>> http://www.wickettraining.com >>>>>> >>>>>> On Sun, Feb 8, 2009 at 2:26 PM, Martin Makundi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Exactly. I had a component with its own converter and my memory >>>>>>> profiler showed that it ended up hogging 200 MB. >>>>>>> >>>>>>> Ofcourse I can organize my own singleton library of converters.. but >>>>>>> Wicket has its own ConverterLocator. I would like to hear if someone >>>>>>> has made such an implementation of ConverterLocator that you can have >>>>>>> 'tuned' converters - instead of just one converter per type. >>>>>>> >>>>>>> ** >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> 2009/2/8 Thomas Mäder <[email protected]>: >>>>>>> > You can override getConverter() on a component to return any converter >>>>>>> you >>>>>>> > want. >>>>>>> > >>>>>>> > Thomas >>>>>>> > >>>>>>> > On Sun, Feb 8, 2009 at 6:53 PM, Martin Makundi < >>>>>>> > [email protected]> wrote: >>>>>>> > >>>>>>> >> Hi! >>>>>>> >> >>>>>>> >> I am a bit confused with the converters in Wicket. I have some >>>>>>> >> numbers >>>>>>> >> which I want to display with two decimals and some other numbers with >>>>>>> >> another amout of decimals. >>>>>>> >> >>>>>>> >> It appears like Wicket has only one instance of BigDecimalConverter, >>>>>>> >> which is used everywhere. So if I adjust its NumberFormat, the effect >>>>>>> >> will be seen everywhere. Is this true? >>>>>>> >> >>>>>>> >> Who knows of an flexible but elegant way to work with the Wicket >>>>>>> >> converters? Creating new converters for each label or textfield >>>>>>> >> results in a lot of garbage in the memory footprint... >>>>>>> >> >>>>>>> >> ** >>>>>>> >> Martin >>>>>>> >> >>>>>>> >> --------------------------------------------------------------------- >>>>>>> >> To unsubscribe, e-mail: [email protected] >>>>>>> >> For additional commands, e-mail: [email protected] >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Thomas Mäder >>>>>>> > Wicket & Eclipse Consulting >>>>>>> > www.devotek-it.ch >>>>>>> > >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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] >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
