> are you load testing wicket in development mode? Ofcourse ;)
I run the tests again in deployment mode, does not affect the BigDecimalConverter results. ** Martin > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
