You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by st...@stantastic.nl on 2023/01/01 21:23:10 UTC
Wicket on low end hardware
Hi,
My use case for Wicket is a quite unconventional one. I use it as the
framework for the web interface of an appliance that runs on low end
hardware. The appliance doesn't have gigabytes of memory to waste or
tens of CPU cores. It's more like Celeron powered hardware with maybe
one or two gigabytes of RAM.
I general this all works and customers are happy once the device is
running. But I find that deployment is quite slow, and so are the first
couple of page loads of the day. Just to be clear: I cannot really claim
that my performance problems are all Wicket related. They may be, but
they probably also are down to other underlying issues. A badly
optimized database, or a badly configured servlet container come to
mind...
However, I was wondering if anyone has experience in using Wicket on low
end hardware. I would be very interested in how to optimize for this.
Thanks,
Stan
Re: Wicket on low end hardware
Posted by François Meillet <fr...@gmail.com>.
Have you try the command line options -verbose:class to list all classes loaded in the JVM at startup ?
For example loading Yauaa (Yet Another UserAgent Analyzer, https://github.com/nielsbasjes/yauaa) or Simple Magic (https://github.com/j256/simplemagic) takes time.
François
> Le 3 janv. 2023 à 16:36, Martin Terra <ma...@koodaripalvelut.com> a écrit :
>
> Just a note, you don't need to make the startup "pre-touching" process a
> blocking one so that if a user were to interact with the app, they could do
> so while startup pretouch is doing its thing.
>
> And you could profile whether you want to do the pre-touch in single thread
> or multi-thraded.
>
> **
> Martin
>
> ti 3. tammik. 2023 klo 16.58 stan@stantastic.nl kirjoitti:
>
>> Thanks everyone. I did not expect the amount of feedback that I got. It
>> is much appreciated.
>>
>> I spent most of my day profiling with VisualVM and it strengthened by
>> beliefs that my problems do not appear to be related to anything but
>> Wicket combined with our dated hardware. Please do not consider this a
>> criticism. I understand that not a lot of people run servlet containers
>> on this kind of hardware nowadays.
>>
>> My database queries all run quickly and my domain classes are hardly
>> even touched when the system starts. Our rather simple login page -
>> which is stateless and does not query the database when the form is
>> empty - takes 5-15 seconds to load on the first try. Subsequent requests
>> take about 40-120ms (browser caching disabled). Once logged in, the
>> other pages do not take as long, but they do feel sluggish until they
>> have been requested once.
>>
>> I tried to only load the quickstart example as Martijn suggested. It
>> starts more quickly than our own application but all things considered,
>> its performance did not impress me and that application really is super
>> simple. The first page load of the quickstart took about 2 seconds,
>> after that it normalized to about 30ms per request.
>>
>> When all pages have been loaded once, things are absolutely fine. So I
>> am considering Martin's approach of preloading components. That still
>> leaves me with the considerable startup time but we will learn to live
>> with that. Or we might switch from Tomcat to Jetty eventually.
>>
>> If anyone thinks I might be leaving some stuff on the table, I would be
>> open to hire someone to do some consulting work on this. Please get in
>> touch with me if you are interested.
>>
>> Cheers.
>>
>> Stan
>>
>>
>> Martin Terra schreef op 2023-01-02 04:29:
>>
>>> Anything in wicket can be preloaded, but as premature optimization is
>>> evil, you should profile your application.
>>>
>>> If you do not have debug access to a real/simulated environment then
>>> the
>>> least you can do is make your own thread logger to log what the threads
>>> are
>>> doing.
>>>
>>> **
>>> Martin
>>>
>>> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
>>> kirjoitti:
>>>
>>>> Hello
>>>>
>>>> Would you please describe your web application components? Database ?
>>>> What services ran on the device?
>>>>
>>>> From: stan@stantastic.nl <st...@stantastic.nl>
>>>> Date: Monday, January 2, 2023 at 5:23 AM
>>>> To: users@wicket.apache.org <us...@wicket.apache.org>
>>>> Subject: Wicket on low end hardware
>>>>
>>>> Hi,
>>>>
>>>> My use case for Wicket is a quite unconventional one. I use it as the
>>>> framework for the web interface of an appliance that runs on low end
>>>> hardware. The appliance doesn't have gigabytes of memory to waste or
>>>> tens of CPU cores. It's more like Celeron powered hardware with maybe
>>>> one or two gigabytes of RAM.
>>>>
>>>> I general this all works and customers are happy once the device is
>>>> running. But I find that deployment is quite slow, and so are the
>>>> first
>>>> couple of page loads of the day. Just to be clear: I cannot really
>>>> claim
>>>> that my performance problems are all Wicket related. They may be, but
>>>> they probably also are down to other underlying issues. A badly
>>>> optimized database, or a badly configured servlet container come to
>>>> mind...
>>>>
>>>> However, I was wondering if anyone has experience in using Wicket on
>>>> low
>>>> end hardware. I would be very interested in how to optimize for this.
>>>>
>>>> Thanks,
>>>>
>>>> Stan
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by "Locke, Jonathan (Luo Shibo)" <jo...@telenav.com>.
One other little tidbit that could help. If you want to see when Hotspot compiles things, you can set the flag -XX:+PrintCompilation.
It would be nice if there was a way to force compilation of everything, but it doesn’t appear to be possible.
Best,
Jon
<https://www.baeldung.com/jvm-tiered-compilation>
[social-Java-On-Baeldung-2.jpg]
Tiered Compilation in JVM<https://www.baeldung.com/jvm-tiered-compilation>
baeldung.com<https://www.baeldung.com/jvm-tiered-compilation>
On Jan 3, 2023, at 6:48 PM, Martin Terra <ma...@koodaripalvelut.com> wrote:
MartinG mentioned ComponentRenderer so if you know your pages, you could do
that.
If you need help with ComponentRenderer, please first proceed with it and
maybe a more specific question might help once you have gotten started.
**
Martin
ke 4. tammik. 2023 klo 2.23 Anna Eileen Eileen (shengchehsiao@gmail.com)
kirjoitti:
Dear Martin
I don’t know how to do “pre-touch”, do you have any example?
From: Martin Terra <ma...@koodaripalvelut.com>
Date: Tuesday, January 3, 2023 at 11:37 PM
To: stan@stantastic.nl <st...@stantastic.nl>
Cc: users@wicket.apache.org <us...@wicket.apache.org>
Subject: Re: Wicket on low end hardware
Just a note, you don't need to make the startup "pre-touching" process a
blocking one so that if a user were to interact with the app, they could do
so while startup pretouch is doing its thing.
And you could profile whether you want to do the pre-touch in single thread
or multi-thraded.
**
Martin
ti 3. tammik. 2023 klo 16.58 stan@stantastic.nl kirjoitti:
Thanks everyone. I did not expect the amount of feedback that I got. It
is much appreciated.
I spent most of my day profiling with VisualVM and it strengthened by
beliefs that my problems do not appear to be related to anything but
Wicket combined with our dated hardware. Please do not consider this a
criticism. I understand that not a lot of people run servlet containers
on this kind of hardware nowadays.
My database queries all run quickly and my domain classes are hardly
even touched when the system starts. Our rather simple login page -
which is stateless and does not query the database when the form is
empty - takes 5-15 seconds to load on the first try. Subsequent requests
take about 40-120ms (browser caching disabled). Once logged in, the
other pages do not take as long, but they do feel sluggish until they
have been requested once.
I tried to only load the quickstart example as Martijn suggested. It
starts more quickly than our own application but all things considered,
its performance did not impress me and that application really is super
simple. The first page load of the quickstart took about 2 seconds,
after that it normalized to about 30ms per request.
When all pages have been loaded once, things are absolutely fine. So I
am considering Martin's approach of preloading components. That still
leaves me with the considerable startup time but we will learn to live
with that. Or we might switch from Tomcat to Jetty eventually.
If anyone thinks I might be leaving some stuff on the table, I would be
open to hire someone to do some consulting work on this. Please get in
touch with me if you are interested.
Cheers.
Stan
Martin Terra schreef op 2023-01-02 04:29:
Anything in wicket can be preloaded, but as premature optimization is
evil, you should profile your application.
If you do not have debug access to a real/simulated environment then
the
least you can do is make your own thread logger to log what the threads
are
doing.
**
Martin
ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
kirjoitti:
Hello
Would you please describe your web application components? Database ?
What services ran on the device?
From: stan@stantastic.nl <st...@stantastic.nl>
Date: Monday, January 2, 2023 at 5:23 AM
To: users@wicket.apache.org <us...@wicket.apache.org>
Subject: Wicket on low end hardware
Hi,
My use case for Wicket is a quite unconventional one. I use it as the
framework for the web interface of an appliance that runs on low end
hardware. The appliance doesn't have gigabytes of memory to waste or
tens of CPU cores. It's more like Celeron powered hardware with maybe
one or two gigabytes of RAM.
I general this all works and customers are happy once the device is
running. But I find that deployment is quite slow, and so are the
first
couple of page loads of the day. Just to be clear: I cannot really
claim
that my performance problems are all Wicket related. They may be, but
they probably also are down to other underlying issues. A badly
optimized database, or a badly configured servlet container come to
mind...
However, I was wondering if anyone has experience in using Wicket on
low
end hardware. I would be very interested in how to optimize for this.
Thanks,
Stan
[EXTERNAL EMAIL] CAUTION: This email originated from outside of Telenav. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Re: Wicket on low end hardware
Posted by Martin Terra <ma...@koodaripalvelut.com>.
MartinG mentioned ComponentRenderer so if you know your pages, you could do
that.
If you need help with ComponentRenderer, please first proceed with it and
maybe a more specific question might help once you have gotten started.
**
Martin
ke 4. tammik. 2023 klo 2.23 Anna Eileen Eileen (shengchehsiao@gmail.com)
kirjoitti:
> Dear Martin
>
> I don’t know how to do “pre-touch”, do you have any example?
>
> From: Martin Terra <ma...@koodaripalvelut.com>
> Date: Tuesday, January 3, 2023 at 11:37 PM
> To: stan@stantastic.nl <st...@stantastic.nl>
> Cc: users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Re: Wicket on low end hardware
> Just a note, you don't need to make the startup "pre-touching" process a
> blocking one so that if a user were to interact with the app, they could do
> so while startup pretouch is doing its thing.
>
> And you could profile whether you want to do the pre-touch in single thread
> or multi-thraded.
>
> **
> Martin
>
> ti 3. tammik. 2023 klo 16.58 stan@stantastic.nl kirjoitti:
>
> > Thanks everyone. I did not expect the amount of feedback that I got. It
> > is much appreciated.
> >
> > I spent most of my day profiling with VisualVM and it strengthened by
> > beliefs that my problems do not appear to be related to anything but
> > Wicket combined with our dated hardware. Please do not consider this a
> > criticism. I understand that not a lot of people run servlet containers
> > on this kind of hardware nowadays.
> >
> > My database queries all run quickly and my domain classes are hardly
> > even touched when the system starts. Our rather simple login page -
> > which is stateless and does not query the database when the form is
> > empty - takes 5-15 seconds to load on the first try. Subsequent requests
> > take about 40-120ms (browser caching disabled). Once logged in, the
> > other pages do not take as long, but they do feel sluggish until they
> > have been requested once.
> >
> > I tried to only load the quickstart example as Martijn suggested. It
> > starts more quickly than our own application but all things considered,
> > its performance did not impress me and that application really is super
> > simple. The first page load of the quickstart took about 2 seconds,
> > after that it normalized to about 30ms per request.
> >
> > When all pages have been loaded once, things are absolutely fine. So I
> > am considering Martin's approach of preloading components. That still
> > leaves me with the considerable startup time but we will learn to live
> > with that. Or we might switch from Tomcat to Jetty eventually.
> >
> > If anyone thinks I might be leaving some stuff on the table, I would be
> > open to hire someone to do some consulting work on this. Please get in
> > touch with me if you are interested.
> >
> > Cheers.
> >
> > Stan
> >
> >
> > Martin Terra schreef op 2023-01-02 04:29:
> >
> > > Anything in wicket can be preloaded, but as premature optimization is
> > > evil, you should profile your application.
> > >
> > > If you do not have debug access to a real/simulated environment then
> > > the
> > > least you can do is make your own thread logger to log what the threads
> > > are
> > > doing.
> > >
> > > **
> > > Martin
> > >
> > > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > > kirjoitti:
> > >
> > >> Hello
> > >>
> > >> Would you please describe your web application components? Database ?
> > >> What services ran on the device?
> > >>
> > >> From: stan@stantastic.nl <st...@stantastic.nl>
> > >> Date: Monday, January 2, 2023 at 5:23 AM
> > >> To: users@wicket.apache.org <us...@wicket.apache.org>
> > >> Subject: Wicket on low end hardware
> > >>
> > >> Hi,
> > >>
> > >> My use case for Wicket is a quite unconventional one. I use it as the
> > >> framework for the web interface of an appliance that runs on low end
> > >> hardware. The appliance doesn't have gigabytes of memory to waste or
> > >> tens of CPU cores. It's more like Celeron powered hardware with maybe
> > >> one or two gigabytes of RAM.
> > >>
> > >> I general this all works and customers are happy once the device is
> > >> running. But I find that deployment is quite slow, and so are the
> > >> first
> > >> couple of page loads of the day. Just to be clear: I cannot really
> > >> claim
> > >> that my performance problems are all Wicket related. They may be, but
> > >> they probably also are down to other underlying issues. A badly
> > >> optimized database, or a badly configured servlet container come to
> > >> mind...
> > >>
> > >> However, I was wondering if anyone has experience in using Wicket on
> > >> low
> > >> end hardware. I would be very interested in how to optimize for this.
> > >>
> > >> Thanks,
> > >>
> > >> Stan
> >
>
Re: Wicket on low end hardware
Posted by st...@stantastic.nl.
Hi,
I basically did what you said for my most troublesome page and added it
to the app.init() method.
I have carried on investigating and have found out that it is mostly
PackageStringResourceLoader that is slowing me down. I added some
logging to Wicket to determine its performance whilst looking up
property keys, and ended up with this for one of the custom first keys
that gets hit:
***
----- comp key: 'wicket_message_attr_1438732643.branding.logo'; class:
'class nl.stantastic.appadmin.pages.LoginPage'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading component key took: 0
----- comp key: 'branding.logo'; class: 'class
nl.stantastic.appadmin.pages.LoginPage'; locale: 'en_US'; Style: 'null';
Variation: 'null'
Loading component key took: 0
----- comp key: 'branding.logo'; class: 'class
org.apache.wicket.markup.html.WebComponent'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading component key took: 69
----- package key: 'wicket_message_attr_1438732643.branding.logo';
class: 'class nl.stantastic.appadmin.pages.LoginPage'; locale: 'en_US';
Style: 'null'; Variation: 'null'
Loading package key took: 731
----- package key: 'branding.logo'; class: 'class
nl.stantastic.appadmin.pages.LoginPage'; locale: 'en_US'; Style: 'null';
Variation: 'null'
Loading package key took: 6
----- package key: 'branding.logo'; class: 'class
org.apache.wicket.markup.html.WebComponent'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading package key took: 1
----- comp key: 'wicket_message_attr_1438732643.branding.logo'; class:
'class nl.stantastic.appadmin.config.DeviceAdminApplication'; locale:
'en_US'; Style: 'null'; Variation: 'null'
Loading component key took: 186
----- comp key: 'branding.logo'; class: 'class
nl.stantastic.appadmin.config.DeviceAdminApplication'; locale: 'en_US';
Style: 'null'; Variation: 'null'
Loading component key took: 0
----- comp key: 'branding.logo'; class: 'class
nl.stantastic.appadmin.config.DeviceAdminApplication'; locale: 'en_US';
Style: 'null'; Variation: 'null'
Loading component key took: 0
----- initializer key: 'branding.logo'; class: 'null'; locale: 'en_US';
Style: 'null'; Variation: 'null'
Loading initializer key took: 134
----- comp key: 'branding.logo'; class: 'class
org.apache.wicket.Initializer'; locale: 'en_US'; Style: 'null';
Variation: 'null'
Loading component key took: 100
----- comp key: 'branding.logo'; class: 'class
org.apache.wicket.extensions.Initializer'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading component key took: 34
----- bundle key: 'branding.logo'; class: 'null'; locale: 'en_US';
Style: 'null'; Variation: 'null'
Loading bundle key took: 6
***
This particular example is being rendered in a wicket:message attribute.
The slowest call is 731ms. All together this easily adds up to 1250ms on
the first run on my development machine that has much much more power
than our production devices. And this is just one of about five slower
keys that I have to run through on the first page load.
Because the branding.logo is in a bundle and I add that bundle to the
end of the StringResourceLoaders, it gets handled last. Makes perfect
sense, I am okay with this.
I can improve the performance by taking out PackageStringResourceLoader,
or moving BundleStringResourceLoader forward. But there still are a
couple of other ones that steal time. Such as Wicket's
'Form.CSS.hidden-fields':
***
----- comp key: 'loginForm.Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.pages.LoginPage'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading component key took: 0
----- comp key: 'Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.pages.LoginPage'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading component key took: 6
----- comp key: 'Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.pages.LoginPage$LoginForm'; locale: 'en_US';
Style: 'null'; Variation: 'null'
Loading component key took: 211
----- package key: 'loginForm.Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.pages.LoginPage'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading package key took: 1
----- package key: 'Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.pages.LoginPage'; locale: 'en_US'; Style:
'null'; Variation: 'null'
Loading package key took: 1
----- package key: 'Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.pages.LoginPage$LoginForm'; locale: 'en_US';
Style: 'null'; Variation: 'null'
Loading package key took: 63
----- comp key: 'loginForm.Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.config.SelfcheckAdminApplication'; locale:
'en_US'; Style: 'null'; Variation: 'null'
Loading component key took: 1
----- comp key: 'Form.CSS.hidden-fields'; class: 'class
nl.stantastic.app.admin.config.SelfcheckAdminApplication'; locale:
'en_US'; Style: 'null'; Variation: 'null'
Loading component key took: 0
***
This takes well over 250ms on the first run.
So I think there's something fishy going on. But I have not been able
put my finger on it yet. I will just keep on debugging for a day or two
I guess. Maybe I will be able to file for a bug if I get to the bottom
of this.
Thanks.
Stan
Martin Grigorov schreef op 2023-01-06 15:01:
> Please explain what you did exactly
>
> On Fri, Jan 6, 2023 at 3:53 PM <st...@stantastic.nl> wrote:
>
> Hi Martin,
>
> Sadly, that does not make any difference.
>
> Martin Grigorov schreef op 2023-01-06 13:19:
>
> In the preloading code please try with:
>
> Application.get()
> .getResourceSettings()
> .getResourceStreamLocator()
> .locate(clazz, path, style, variation, locale, (String) null, false)
>
> where
> clazz is AnyOfYourPagesAndMarkupContainersWithProperties.class
> path is clazz.getName().replace('.', '/')
> locale is NL
> style is null
> variation is null
>
> does it help ?
>
> On Fri, Jan 6, 2023 at 2:10 PM <st...@stantastic.nl> wrote:
>
> Hi Martin,
>
> My system locale is nl.
>
> The application's default language is English. But all properties files
> have '_nl' counterparts, so the application runs in Dutch as well as it
> does in English. Most users use the Dutch locale.
>
> Every WebPage has an English (default) properties file, and a Dutch
> one.
> There also is a MyApplication.properties and a
> MyApplication_nl.properties. I also add an extra resource bundle that I
> use to rebrand the application for a subcontractor if that is
> necessary.
> That one is being added in the app.init() code using:
>
> getResourceSettings().getStringResourceLoaders().add(new
> BundleStringResourceLoader("RebrandSubcontractorName"));
>
> A quick count tells me that my application has about 85 *.properties
> files.
>
> Stan
>
> Martin Grigorov schreef op 2023-01-06 12:59:
>
> On Fri, Jan 6, 2023 at 11:44 AM <st...@stantastic.nl> wrote:
>
> Hi all,
>
> As I was implementing markup caching by adding it directly to the
> MarkupCache, I found my gains weren't as big as I had expected (I
> guess
> premature optimization really is the root of all evil...). My tests
> using ComponentRenderer were much more promising.
>
> So I started to dig into this deeper and found that the first call to
> Localizer->getString() on our hardware takes between 1500 and 2000ms.
> I
> then started to investigate if this can also be preloaded but I am
> having a hard time coming up with something effective.
>
> Does anyone have experience with this?
> What is the system locale ?
> And what resource bunldes does your application use ? E.g.
> MyApplication_nl.properties and MyApplication.properties
>
> Thanks.
>
> Stan
>
> Martin Grigorov schreef op 2023-01-06 09:52:
>
> Hi,
>
> Here is the minimum for preloading the markup of any MarkupContainer:
>
> MarkupFactory markupFactory =
> Application.get().getMarkupSettings().getMarkupFactory();
> markupFactory.getMarkup(new AnyMarkupContainer(), false);
>
> AnyMarkupContainer could be a Page, Panel, Border, ..., any
> MarkupContainer
> impl.
> The Markup will be stored in the MarkupCache for the following needs.
>
> On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
> wrote:
>
> You can render components, not just pages
>
> According to the list
> You can create the list of all HTML files, find correspondent Java
> files
> and try to render them
>
> from mobile (sorry for typos ;)
>
> On Fri, Jan 6, 2023, 01:20 Chris Colman
> <ch...@stepaheadsoftware.com.invalid> wrote:
>
> In my case I have lots of modal forms (using Wicketstuff ModalX) that
> can be potentially opened by the user.
>
> Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> all of those modal forms as the page markup has no reference to the
> modal form contents/markup as it is using ModalX's generic modal dialog
> feature so there's no need to specify which form you wish to open in
> the
> markup of the page that will open it.
>
> I wonder if it would be possible to develop a 'parse all markup' that
> would pick up the markup for these forms as well, not just for the
> pages.
>
> On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
> 2:48 PM<st...@stantastic.nl> wrote:
>
> Hi Anna,
>
> I attempted this, and ended up with a method like this:
>
> private void preloadPages(Collection<Class<? extends
> IRequestablePage>>
>
> pages) {
> final Supplier<ISessionStore> oldSessionStoreProvider =
> getSessionStoreProvider();
>
> try {
> setSessionStoreProvider(() -> new MockSessionStore());
>
> final RequestCycle rc = createRequestCycle(new MockWebRequest(new
>
> Url()), new MockWebResponse());
> ThreadContext.setRequestCycle(rc);
>
> for (Class<? extends IRequestablePage> p : pages)
> ComponentRenderer.renderPage(new PageProvider(p));
> }
> finally {
> setSessionStoreProvider(oldSessionStoreProvider);
> }
> }
>
> Which I have not been able to test on more than one page yet, because
> I
>
> still need to implement something to render my other pages with an
> AuthenticatedWebSession. My login page's first load time has been
> reduced to about 10% of what it was though.
>
> I call that method from app.init().
>
> I have some doubts over Martin's claim that it is possible to do this
> on
>
> a different thread. As you may notice, I had to change the
> SessionStoreProvider to make this work. If I am correct that means
> that
>
> as long as this method runs, all sessions will be handled by the
> MockSessionStore.
>
> Stan
>
> Anna Eileen Eileen schreef op 2023-01-04 01:22:
>
> Dear Martin
>
> I don't know how to do "pre-touch", do you have any example?
>
> From: Martin Terra<ma...@koodaripalvelut.com>
> Date: Tuesday, January 3, 2023 at 11:37 PM
> To:stan@stantastic.nl <st...@stantastic.nl>
> Cc:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Re: Wicket on low end hardware
> Just a note, you don't need to make the startup "pre-touching"
> process
>
> a
> blocking one so that if a user were to interact with the app, they
> could do
> so while startup pretouch is doing its thing.
>
> And you could profile whether you want to do the pre-touch in single
> thread
> or multi-thraded.
>
> **
> Martin
>
> ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
>
> Thanks everyone. I did not expect the amount of feedback that I got.
> It
>
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this
> a
>
> criticism. I understand that not a lot of people run servlet
> containers
>
> on this kind of hardware nowadays.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent
> requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things
> considered,
>
> its performance did not impress me and that application really is
> super
>
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So
> I
>
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to
> live
>
> with that. Or we might switch from Tomcat to Jetty eventually. You
> may want to check the implementation of Wicket Native WebSocket
> module
>
> [1]
> WebSocket messages come in a TCP connection, i.e. there is no HTTP
> session/request/response.
> Because of that Wicket Native WebSocket stores the app name, session
> id,
>
> page id / resource name at the handshake time and later fetches /
> re-creates those to process any websocket message.
>
> I agree that the setup is not something simple. Loading a page may
> depend
>
> on external resources (like a user in your case, or an open DB
> connection,
>
> ...).
> Maybe you can simplify the preloading to just populate the Markup
> cache
> instead of fully render all pages.
> IMO this deserves to be added to Wicket APIs as a helper or something!
> 1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
> If anyone thinks I might be leaving some stuff on the table, I would
be
> open to hire someone to do some consulting work on this. Please get
in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> Anything in wicket can be preloaded, but as premature optimization
is
> evil, you should profile your application.
>
> If you do not have debug access to a real/simulated environment then
> the
> least you can do is make your own thread logger to log what the
threads
> are
> doing.
>
> **
> Martin
>
> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> kirjoitti:
>
> Hello
>
> Would you please describe your web application components? Database ?
> What services ran on the device?
>
> From:stan@stantastic.nl <st...@stantastic.nl>
> Date: Monday, January 2, 2023 at 5:23 AM
> To:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Wicket on low end hardware
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the
> first
> couple of page loads of the day. Just to be clear: I cannot really
> claim
> that my performance problems are all Wicket related. They may be, but
> they probably also are down to other underlying issues. A badly
> optimized database, or a badly configured servlet container come to
> mind...
>
> However, I was wondering if anyone has experience in using Wicket on
> low
> end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> For additional commands, e-mail:users-help@wicket.apache.org
--
Regards,
Chris Colman
*Feezily*,
A product of /Step Ahead/ *Software* Pty Ltd
Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
Ph: 02 9656 1278
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by Martin Grigorov <mg...@apache.org>.
Please explain what you did exactly
On Fri, Jan 6, 2023 at 3:53 PM <st...@stantastic.nl> wrote:
> Hi Martin,
>
> Sadly, that does not make any difference.
>
>
> Martin Grigorov schreef op 2023-01-06 13:19:
>
> > In the preloading code please try with:
> >
> > Application.get()
> > .getResourceSettings()
> > .getResourceStreamLocator()
> > .locate(clazz, path, style, variation, locale, (String) null, false)
> >
> > where
> > clazz is AnyOfYourPagesAndMarkupContainersWithProperties.class
> > path is clazz.getName().replace('.', '/')
> > locale is NL
> > style is null
> > variation is null
> >
> > does it help ?
> >
> > On Fri, Jan 6, 2023 at 2:10 PM <st...@stantastic.nl> wrote:
> >
> > Hi Martin,
> >
> > My system locale is nl.
> >
> > The application's default language is English. But all properties files
> > have '_nl' counterparts, so the application runs in Dutch as well as it
> > does in English. Most users use the Dutch locale.
> >
> > Every WebPage has an English (default) properties file, and a Dutch
> > one.
> > There also is a MyApplication.properties and a
> > MyApplication_nl.properties. I also add an extra resource bundle that I
> > use to rebrand the application for a subcontractor if that is
> > necessary.
> > That one is being added in the app.init() code using:
> >
> > getResourceSettings().getStringResourceLoaders().add(new
> > BundleStringResourceLoader("RebrandSubcontractorName"));
> >
> > A quick count tells me that my application has about 85 *.properties
> > files.
> >
> > Stan
> >
> > Martin Grigorov schreef op 2023-01-06 12:59:
> >
> > On Fri, Jan 6, 2023 at 11:44 AM <st...@stantastic.nl> wrote:
> >
> > Hi all,
> >
> > As I was implementing markup caching by adding it directly to the
> > MarkupCache, I found my gains weren't as big as I had expected (I
> > guess
> > premature optimization really is the root of all evil...). My tests
> > using ComponentRenderer were much more promising.
> >
> > So I started to dig into this deeper and found that the first call to
> > Localizer->getString() on our hardware takes between 1500 and 2000ms.
> > I
> > then started to investigate if this can also be preloaded but I am
> > having a hard time coming up with something effective.
> >
> > Does anyone have experience with this?
> > What is the system locale ?
> > And what resource bunldes does your application use ? E.g.
> > MyApplication_nl.properties and MyApplication.properties
> >
> > Thanks.
> >
> > Stan
> >
> > Martin Grigorov schreef op 2023-01-06 09:52:
> >
> > Hi,
> >
> > Here is the minimum for preloading the markup of any MarkupContainer:
> >
> > MarkupFactory markupFactory =
> > Application.get().getMarkupSettings().getMarkupFactory();
> > markupFactory.getMarkup(new AnyMarkupContainer(), false);
> >
> > AnyMarkupContainer could be a Page, Panel, Border, ..., any
> > MarkupContainer
> > impl.
> > The Markup will be stored in the MarkupCache for the following needs.
> >
> > On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
> > wrote:
> >
> > You can render components, not just pages
> >
> > According to the list
> > You can create the list of all HTML files, find correspondent Java
> > files
> > and try to render them
> >
> > from mobile (sorry for typos ;)
> >
> > On Fri, Jan 6, 2023, 01:20 Chris Colman
> > <ch...@stepaheadsoftware.com.invalid> wrote:
> >
> > In my case I have lots of modal forms (using Wicketstuff ModalX) that
> > can be potentially opened by the user.
> >
> > Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> > all of those modal forms as the page markup has no reference to the
> > modal form contents/markup as it is using ModalX's generic modal dialog
> > feature so there's no need to specify which form you wish to open in
> > the
> > markup of the page that will open it.
> >
> > I wonder if it would be possible to develop a 'parse all markup' that
> > would pick up the markup for these forms as well, not just for the
> > pages.
> >
> > On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
> > 2:48 PM<st...@stantastic.nl> wrote:
> >
> > Hi Anna,
> >
> > I attempted this, and ended up with a method like this:
> >
> > private void preloadPages(Collection<Class<? extends
> > IRequestablePage>>
> >
> > pages) {
> > final Supplier<ISessionStore> oldSessionStoreProvider =
> > getSessionStoreProvider();
> >
> > try {
> > setSessionStoreProvider(() -> new MockSessionStore());
> >
> > final RequestCycle rc = createRequestCycle(new MockWebRequest(new
> >
> > Url()), new MockWebResponse());
> > ThreadContext.setRequestCycle(rc);
> >
> > for (Class<? extends IRequestablePage> p : pages)
> > ComponentRenderer.renderPage(new PageProvider(p));
> > }
> > finally {
> > setSessionStoreProvider(oldSessionStoreProvider);
> > }
> > }
> >
> > Which I have not been able to test on more than one page yet, because
> > I
> >
> > still need to implement something to render my other pages with an
> > AuthenticatedWebSession. My login page's first load time has been
> > reduced to about 10% of what it was though.
> >
> > I call that method from app.init().
> >
> > I have some doubts over Martin's claim that it is possible to do this
> > on
> >
> > a different thread. As you may notice, I had to change the
> > SessionStoreProvider to make this work. If I am correct that means
> > that
> >
> > as long as this method runs, all sessions will be handled by the
> > MockSessionStore.
> >
> > Stan
> >
> > Anna Eileen Eileen schreef op 2023-01-04 01:22:
> >
> > Dear Martin
> >
> > I don't know how to do "pre-touch", do you have any example?
> >
> > From: Martin Terra<ma...@koodaripalvelut.com>
> > Date: Tuesday, January 3, 2023 at 11:37 PM
> > To:stan@stantastic.nl <st...@stantastic.nl>
> > Cc:users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Re: Wicket on low end hardware
> > Just a note, you don't need to make the startup "pre-touching"
> > process
> >
> > a
> > blocking one so that if a user were to interact with the app, they
> > could do
> > so while startup pretouch is doing its thing.
> >
> > And you could profile whether you want to do the pre-touch in single
> > thread
> > or multi-thraded.
> >
> > **
> > Martin
> >
> > ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
> >
> > Thanks everyone. I did not expect the amount of feedback that I got.
> > It
> >
> > is much appreciated.
> >
> > I spent most of my day profiling with VisualVM and it strengthened by
> > beliefs that my problems do not appear to be related to anything but
> > Wicket combined with our dated hardware. Please do not consider this
> > a
> >
> > criticism. I understand that not a lot of people run servlet
> > containers
> >
> > on this kind of hardware nowadays.
> >
> > My database queries all run quickly and my domain classes are hardly
> > even touched when the system starts. Our rather simple login page -
> > which is stateless and does not query the database when the form is
> > empty - takes 5-15 seconds to load on the first try. Subsequent
> > requests
> > take about 40-120ms (browser caching disabled). Once logged in, the
> > other pages do not take as long, but they do feel sluggish until they
> > have been requested once.
> >
> > I tried to only load the quickstart example as Martijn suggested. It
> > starts more quickly than our own application but all things
> > considered,
> >
> > its performance did not impress me and that application really is
> > super
> >
> > simple. The first page load of the quickstart took about 2 seconds,
> > after that it normalized to about 30ms per request.
> >
> > When all pages have been loaded once, things are absolutely fine. So
> > I
> >
> > am considering Martin's approach of preloading components. That still
> > leaves me with the considerable startup time but we will learn to
> > live
> >
> > with that. Or we might switch from Tomcat to Jetty eventually. You
> > may want to check the implementation of Wicket Native WebSocket
> > module
> >
> > [1]
> > WebSocket messages come in a TCP connection, i.e. there is no HTTP
> > session/request/response.
> > Because of that Wicket Native WebSocket stores the app name, session
> > id,
> >
> > page id / resource name at the handshake time and later fetches /
> > re-creates those to process any websocket message.
> >
> > I agree that the setup is not something simple. Loading a page may
> depend
>
> >> on external resources (like a user in your case, or an open DB
> > connection,
> >
> >> ...).
> >> Maybe you can simplify the preloading to just populate the Markup
> >> cache
> >> instead of fully render all pages.
> >> IMO this deserves to be added to Wicket APIs as a helper or something!
> >> 1.
>
>
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
>
> > If anyone thinks I might be leaving some stuff on the table, I would
> be
>
> > open to hire someone to do some consulting work on this. Please get
> in
>
> > touch with me if you are interested.
> >
> > Cheers.
> >
> > Stan
> >
> > Martin Terra schreef op 2023-01-02 04:29:
> >
> > Anything in wicket can be preloaded, but as premature optimization
> is
>
> > evil, you should profile your application.
> >
> > If you do not have debug access to a real/simulated environment then
> > the
> > least you can do is make your own thread logger to log what the
> threads
>
> > are
> > doing.
> >
> > **
> > Martin
> >
> > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > kirjoitti:
> >
> > Hello
> >
> > Would you please describe your web application components? Database ?
> > What services ran on the device?
> >
> > From:stan@stantastic.nl <st...@stantastic.nl>
> > Date: Monday, January 2, 2023 at 5:23 AM
> > To:users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Wicket on low end hardware
> >
> > Hi,
> >
> > My use case for Wicket is a quite unconventional one. I use it as the
> > framework for the web interface of an appliance that runs on low end
> > hardware. The appliance doesn't have gigabytes of memory to waste or
> > tens of CPU cores. It's more like Celeron powered hardware with maybe
> > one or two gigabytes of RAM.
> >
> > I general this all works and customers are happy once the device is
> > running. But I find that deployment is quite slow, and so are the
> > first
> > couple of page loads of the day. Just to be clear: I cannot really
> > claim
> > that my performance problems are all Wicket related. They may be, but
> > they probably also are down to other underlying issues. A badly
> > optimized database, or a badly configured servlet container come to
> > mind...
> >
> > However, I was wondering if anyone has experience in using Wicket on
> > low
> > end hardware. I would be very interested in how to optimize for this.
> >
> > Thanks,
> >
> > Stan
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail:users-help@wicket.apache.org
> --
> Regards,
>
> Chris Colman
> *Feezily*,
> A product of /Step Ahead/ *Software* Pty Ltd
> Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
> Ph: 02 9656 1278
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket on low end hardware
Posted by st...@stantastic.nl.
Hi Martin,
Sadly, that does not make any difference.
Martin Grigorov schreef op 2023-01-06 13:19:
> In the preloading code please try with:
>
> Application.get()
> .getResourceSettings()
> .getResourceStreamLocator()
> .locate(clazz, path, style, variation, locale, (String) null, false)
>
> where
> clazz is AnyOfYourPagesAndMarkupContainersWithProperties.class
> path is clazz.getName().replace('.', '/')
> locale is NL
> style is null
> variation is null
>
> does it help ?
>
> On Fri, Jan 6, 2023 at 2:10 PM <st...@stantastic.nl> wrote:
>
> Hi Martin,
>
> My system locale is nl.
>
> The application's default language is English. But all properties files
> have '_nl' counterparts, so the application runs in Dutch as well as it
> does in English. Most users use the Dutch locale.
>
> Every WebPage has an English (default) properties file, and a Dutch
> one.
> There also is a MyApplication.properties and a
> MyApplication_nl.properties. I also add an extra resource bundle that I
> use to rebrand the application for a subcontractor if that is
> necessary.
> That one is being added in the app.init() code using:
>
> getResourceSettings().getStringResourceLoaders().add(new
> BundleStringResourceLoader("RebrandSubcontractorName"));
>
> A quick count tells me that my application has about 85 *.properties
> files.
>
> Stan
>
> Martin Grigorov schreef op 2023-01-06 12:59:
>
> On Fri, Jan 6, 2023 at 11:44 AM <st...@stantastic.nl> wrote:
>
> Hi all,
>
> As I was implementing markup caching by adding it directly to the
> MarkupCache, I found my gains weren't as big as I had expected (I
> guess
> premature optimization really is the root of all evil...). My tests
> using ComponentRenderer were much more promising.
>
> So I started to dig into this deeper and found that the first call to
> Localizer->getString() on our hardware takes between 1500 and 2000ms.
> I
> then started to investigate if this can also be preloaded but I am
> having a hard time coming up with something effective.
>
> Does anyone have experience with this?
> What is the system locale ?
> And what resource bunldes does your application use ? E.g.
> MyApplication_nl.properties and MyApplication.properties
>
> Thanks.
>
> Stan
>
> Martin Grigorov schreef op 2023-01-06 09:52:
>
> Hi,
>
> Here is the minimum for preloading the markup of any MarkupContainer:
>
> MarkupFactory markupFactory =
> Application.get().getMarkupSettings().getMarkupFactory();
> markupFactory.getMarkup(new AnyMarkupContainer(), false);
>
> AnyMarkupContainer could be a Page, Panel, Border, ..., any
> MarkupContainer
> impl.
> The Markup will be stored in the MarkupCache for the following needs.
>
> On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
> wrote:
>
> You can render components, not just pages
>
> According to the list
> You can create the list of all HTML files, find correspondent Java
> files
> and try to render them
>
> from mobile (sorry for typos ;)
>
> On Fri, Jan 6, 2023, 01:20 Chris Colman
> <ch...@stepaheadsoftware.com.invalid> wrote:
>
> In my case I have lots of modal forms (using Wicketstuff ModalX) that
> can be potentially opened by the user.
>
> Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> all of those modal forms as the page markup has no reference to the
> modal form contents/markup as it is using ModalX's generic modal dialog
> feature so there's no need to specify which form you wish to open in
> the
> markup of the page that will open it.
>
> I wonder if it would be possible to develop a 'parse all markup' that
> would pick up the markup for these forms as well, not just for the
> pages.
>
> On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
> 2:48 PM<st...@stantastic.nl> wrote:
>
> Hi Anna,
>
> I attempted this, and ended up with a method like this:
>
> private void preloadPages(Collection<Class<? extends
> IRequestablePage>>
>
> pages) {
> final Supplier<ISessionStore> oldSessionStoreProvider =
> getSessionStoreProvider();
>
> try {
> setSessionStoreProvider(() -> new MockSessionStore());
>
> final RequestCycle rc = createRequestCycle(new MockWebRequest(new
>
> Url()), new MockWebResponse());
> ThreadContext.setRequestCycle(rc);
>
> for (Class<? extends IRequestablePage> p : pages)
> ComponentRenderer.renderPage(new PageProvider(p));
> }
> finally {
> setSessionStoreProvider(oldSessionStoreProvider);
> }
> }
>
> Which I have not been able to test on more than one page yet, because
> I
>
> still need to implement something to render my other pages with an
> AuthenticatedWebSession. My login page's first load time has been
> reduced to about 10% of what it was though.
>
> I call that method from app.init().
>
> I have some doubts over Martin's claim that it is possible to do this
> on
>
> a different thread. As you may notice, I had to change the
> SessionStoreProvider to make this work. If I am correct that means
> that
>
> as long as this method runs, all sessions will be handled by the
> MockSessionStore.
>
> Stan
>
> Anna Eileen Eileen schreef op 2023-01-04 01:22:
>
> Dear Martin
>
> I don't know how to do "pre-touch", do you have any example?
>
> From: Martin Terra<ma...@koodaripalvelut.com>
> Date: Tuesday, January 3, 2023 at 11:37 PM
> To:stan@stantastic.nl <st...@stantastic.nl>
> Cc:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Re: Wicket on low end hardware
> Just a note, you don't need to make the startup "pre-touching"
> process
>
> a
> blocking one so that if a user were to interact with the app, they
> could do
> so while startup pretouch is doing its thing.
>
> And you could profile whether you want to do the pre-touch in single
> thread
> or multi-thraded.
>
> **
> Martin
>
> ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
>
> Thanks everyone. I did not expect the amount of feedback that I got.
> It
>
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this
> a
>
> criticism. I understand that not a lot of people run servlet
> containers
>
> on this kind of hardware nowadays.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent
> requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things
> considered,
>
> its performance did not impress me and that application really is
> super
>
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So
> I
>
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to
> live
>
> with that. Or we might switch from Tomcat to Jetty eventually. You
> may want to check the implementation of Wicket Native WebSocket
> module
>
> [1]
> WebSocket messages come in a TCP connection, i.e. there is no HTTP
> session/request/response.
> Because of that Wicket Native WebSocket stores the app name, session
> id,
>
> page id / resource name at the handshake time and later fetches /
> re-creates those to process any websocket message.
>
> I agree that the setup is not something simple. Loading a page may
depend
>> on external resources (like a user in your case, or an open DB
> connection,
>
>> ...).
>> Maybe you can simplify the preloading to just populate the Markup
>> cache
>> instead of fully render all pages.
>> IMO this deserves to be added to Wicket APIs as a helper or something!
>> 1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
> If anyone thinks I might be leaving some stuff on the table, I would
be
> open to hire someone to do some consulting work on this. Please get
in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> Anything in wicket can be preloaded, but as premature optimization
is
> evil, you should profile your application.
>
> If you do not have debug access to a real/simulated environment then
> the
> least you can do is make your own thread logger to log what the
threads
> are
> doing.
>
> **
> Martin
>
> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> kirjoitti:
>
> Hello
>
> Would you please describe your web application components? Database ?
> What services ran on the device?
>
> From:stan@stantastic.nl <st...@stantastic.nl>
> Date: Monday, January 2, 2023 at 5:23 AM
> To:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Wicket on low end hardware
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the
> first
> couple of page loads of the day. Just to be clear: I cannot really
> claim
> that my performance problems are all Wicket related. They may be, but
> they probably also are down to other underlying issues. A badly
> optimized database, or a badly configured servlet container come to
> mind...
>
> However, I was wondering if anyone has experience in using Wicket on
> low
> end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> For additional commands, e-mail:users-help@wicket.apache.org
--
Regards,
Chris Colman
*Feezily*,
A product of /Step Ahead/ *Software* Pty Ltd
Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
Ph: 02 9656 1278
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by Martin Grigorov <mg...@apache.org>.
In the preloading code please try with:
Application.get()
.getResourceSettings()
.getResourceStreamLocator()
.locate(clazz, path, style, variation, locale, (String) null, false)
where
clazz is AnyOfYourPagesAndMarkupContainersWithProperties.class
path is clazz.getName().replace('.', '/')
locale is NL
style is null
variation is null
does it help ?
On Fri, Jan 6, 2023 at 2:10 PM <st...@stantastic.nl> wrote:
> Hi Martin,
>
> My system locale is nl.
>
> The application's default language is English. But all properties files
> have '_nl' counterparts, so the application runs in Dutch as well as it
> does in English. Most users use the Dutch locale.
>
> Every WebPage has an English (default) properties file, and a Dutch one.
> There also is a MyApplication.properties and a
> MyApplication_nl.properties. I also add an extra resource bundle that I
> use to rebrand the application for a subcontractor if that is necessary.
> That one is being added in the app.init() code using:
>
> getResourceSettings().getStringResourceLoaders().add(new
> BundleStringResourceLoader("RebrandSubcontractorName"));
>
> A quick count tells me that my application has about 85 *.properties
> files.
>
> Stan
>
>
> Martin Grigorov schreef op 2023-01-06 12:59:
>
> > On Fri, Jan 6, 2023 at 11:44 AM <st...@stantastic.nl> wrote:
> >
> >> Hi all,
> >>
> >> As I was implementing markup caching by adding it directly to the
> >> MarkupCache, I found my gains weren't as big as I had expected (I
> >> guess
> >> premature optimization really is the root of all evil...). My tests
> >> using ComponentRenderer were much more promising.
> >>
> >> So I started to dig into this deeper and found that the first call to
> >> Localizer->getString() on our hardware takes between 1500 and 2000ms.
> >> I
> >> then started to investigate if this can also be preloaded but I am
> >> having a hard time coming up with something effective.
> >>
> >> Does anyone have experience with this?
> >
> > What is the system locale ?
> > And what resource bunldes does your application use ? E.g.
> > MyApplication_nl.properties and MyApplication.properties
> >
> > Thanks.
> >
> > Stan
> >
> > Martin Grigorov schreef op 2023-01-06 09:52:
> >
> > Hi,
> >
> > Here is the minimum for preloading the markup of any MarkupContainer:
> >
> > MarkupFactory markupFactory =
> > Application.get().getMarkupSettings().getMarkupFactory();
> > markupFactory.getMarkup(new AnyMarkupContainer(), false);
> >
> > AnyMarkupContainer could be a Page, Panel, Border, ..., any
> > MarkupContainer
> > impl.
> > The Markup will be stored in the MarkupCache for the following needs.
> >
> > On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
> > wrote:
> >
> > You can render components, not just pages
> >
> > According to the list
> > You can create the list of all HTML files, find correspondent Java
> > files
> > and try to render them
> >
> > from mobile (sorry for typos ;)
> >
> > On Fri, Jan 6, 2023, 01:20 Chris Colman
> > <ch...@stepaheadsoftware.com.invalid> wrote:
> >
> > In my case I have lots of modal forms (using Wicketstuff ModalX) that
> > can be potentially opened by the user.
> >
> > Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> > all of those modal forms as the page markup has no reference to the
> > modal form contents/markup as it is using ModalX's generic modal dialog
> > feature so there's no need to specify which form you wish to open in
> > the
> > markup of the page that will open it.
> >
> > I wonder if it would be possible to develop a 'parse all markup' that
> > would pick up the markup for these forms as well, not just for the
> > pages.
> >
> > On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
> > 2:48 PM<st...@stantastic.nl> wrote:
> >
> > Hi Anna,
> >
> > I attempted this, and ended up with a method like this:
> >
> > private void preloadPages(Collection<Class<? extends
> > IRequestablePage>>
> >
> > pages) {
> > final Supplier<ISessionStore> oldSessionStoreProvider =
> > getSessionStoreProvider();
> >
> > try {
> > setSessionStoreProvider(() -> new MockSessionStore());
> >
> > final RequestCycle rc = createRequestCycle(new MockWebRequest(new
> >
> > Url()), new MockWebResponse());
> > ThreadContext.setRequestCycle(rc);
> >
> > for (Class<? extends IRequestablePage> p : pages)
> > ComponentRenderer.renderPage(new PageProvider(p));
> > }
> > finally {
> > setSessionStoreProvider(oldSessionStoreProvider);
> > }
> > }
> >
> > Which I have not been able to test on more than one page yet, because
> > I
> >
> > still need to implement something to render my other pages with an
> > AuthenticatedWebSession. My login page's first load time has been
> > reduced to about 10% of what it was though.
> >
> > I call that method from app.init().
> >
> > I have some doubts over Martin's claim that it is possible to do this
> > on
> >
> > a different thread. As you may notice, I had to change the
> > SessionStoreProvider to make this work. If I am correct that means
> > that
> >
> > as long as this method runs, all sessions will be handled by the
> > MockSessionStore.
> >
> > Stan
> >
> > Anna Eileen Eileen schreef op 2023-01-04 01:22:
> >
> > Dear Martin
> >
> > I don't know how to do "pre-touch", do you have any example?
> >
> > From: Martin Terra<ma...@koodaripalvelut.com>
> > Date: Tuesday, January 3, 2023 at 11:37 PM
> > To:stan@stantastic.nl <st...@stantastic.nl>
> > Cc:users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Re: Wicket on low end hardware
> > Just a note, you don't need to make the startup "pre-touching"
> > process
> >
> > a
> > blocking one so that if a user were to interact with the app, they
> > could do
> > so while startup pretouch is doing its thing.
> >
> > And you could profile whether you want to do the pre-touch in single
> > thread
> > or multi-thraded.
> >
> > **
> > Martin
> >
> > ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
> >
> > Thanks everyone. I did not expect the amount of feedback that I got.
> > It
> >
> > is much appreciated.
> >
> > I spent most of my day profiling with VisualVM and it strengthened by
> > beliefs that my problems do not appear to be related to anything but
> > Wicket combined with our dated hardware. Please do not consider this
> > a
> >
> > criticism. I understand that not a lot of people run servlet
> > containers
> >
> > on this kind of hardware nowadays.
> >
> > My database queries all run quickly and my domain classes are hardly
> > even touched when the system starts. Our rather simple login page -
> > which is stateless and does not query the database when the form is
> > empty - takes 5-15 seconds to load on the first try. Subsequent
> > requests
> > take about 40-120ms (browser caching disabled). Once logged in, the
> > other pages do not take as long, but they do feel sluggish until they
> > have been requested once.
> >
> > I tried to only load the quickstart example as Martijn suggested. It
> > starts more quickly than our own application but all things
> > considered,
> >
> > its performance did not impress me and that application really is
> > super
> >
> > simple. The first page load of the quickstart took about 2 seconds,
> > after that it normalized to about 30ms per request.
> >
> > When all pages have been loaded once, things are absolutely fine. So
> > I
> >
> > am considering Martin's approach of preloading components. That still
> > leaves me with the considerable startup time but we will learn to
> > live
> >
> > with that. Or we might switch from Tomcat to Jetty eventually. You
> > may want to check the implementation of Wicket Native WebSocket
> > module
> >
> > [1]
> > WebSocket messages come in a TCP connection, i.e. there is no HTTP
> > session/request/response.
> > Because of that Wicket Native WebSocket stores the app name, session
> > id,
> >
> > page id / resource name at the handshake time and later fetches /
> > re-creates those to process any websocket message.
> >
> > I agree that the setup is not something simple. Loading a page may
> depend
>
> >> on external resources (like a user in your case, or an open DB
> > connection,
> >
> >> ...).
> >> Maybe you can simplify the preloading to just populate the Markup
> >> cache
> >> instead of fully render all pages.
> >> IMO this deserves to be added to Wicket APIs as a helper or something!
> >> 1.
>
>
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
>
> > If anyone thinks I might be leaving some stuff on the table, I would
> be
>
> > open to hire someone to do some consulting work on this. Please get
> in
>
> > touch with me if you are interested.
> >
> > Cheers.
> >
> > Stan
> >
> > Martin Terra schreef op 2023-01-02 04:29:
> >
> > Anything in wicket can be preloaded, but as premature optimization
> is
>
> > evil, you should profile your application.
> >
> > If you do not have debug access to a real/simulated environment then
> > the
> > least you can do is make your own thread logger to log what the
> threads
>
> > are
> > doing.
> >
> > **
> > Martin
> >
> > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > kirjoitti:
> >
> > Hello
> >
> > Would you please describe your web application components? Database ?
> > What services ran on the device?
> >
> > From:stan@stantastic.nl <st...@stantastic.nl>
> > Date: Monday, January 2, 2023 at 5:23 AM
> > To:users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Wicket on low end hardware
> >
> > Hi,
> >
> > My use case for Wicket is a quite unconventional one. I use it as the
> > framework for the web interface of an appliance that runs on low end
> > hardware. The appliance doesn't have gigabytes of memory to waste or
> > tens of CPU cores. It's more like Celeron powered hardware with maybe
> > one or two gigabytes of RAM.
> >
> > I general this all works and customers are happy once the device is
> > running. But I find that deployment is quite slow, and so are the
> > first
> > couple of page loads of the day. Just to be clear: I cannot really
> > claim
> > that my performance problems are all Wicket related. They may be, but
> > they probably also are down to other underlying issues. A badly
> > optimized database, or a badly configured servlet container come to
> > mind...
> >
> > However, I was wondering if anyone has experience in using Wicket on
> > low
> > end hardware. I would be very interested in how to optimize for this.
> >
> > Thanks,
> >
> > Stan
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail:users-help@wicket.apache.org
> --
> Regards,
>
> Chris Colman
> *Feezily*,
> A product of /Step Ahead/ *Software* Pty Ltd
> Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
> Ph: 02 9656 1278
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Wicket on low end hardware
Posted by st...@stantastic.nl.
Hi Martin,
My system locale is nl.
The application's default language is English. But all properties files
have '_nl' counterparts, so the application runs in Dutch as well as it
does in English. Most users use the Dutch locale.
Every WebPage has an English (default) properties file, and a Dutch one.
There also is a MyApplication.properties and a
MyApplication_nl.properties. I also add an extra resource bundle that I
use to rebrand the application for a subcontractor if that is necessary.
That one is being added in the app.init() code using:
getResourceSettings().getStringResourceLoaders().add(new
BundleStringResourceLoader("RebrandSubcontractorName"));
A quick count tells me that my application has about 85 *.properties
files.
Stan
Martin Grigorov schreef op 2023-01-06 12:59:
> On Fri, Jan 6, 2023 at 11:44 AM <st...@stantastic.nl> wrote:
>
>> Hi all,
>>
>> As I was implementing markup caching by adding it directly to the
>> MarkupCache, I found my gains weren't as big as I had expected (I
>> guess
>> premature optimization really is the root of all evil...). My tests
>> using ComponentRenderer were much more promising.
>>
>> So I started to dig into this deeper and found that the first call to
>> Localizer->getString() on our hardware takes between 1500 and 2000ms.
>> I
>> then started to investigate if this can also be preloaded but I am
>> having a hard time coming up with something effective.
>>
>> Does anyone have experience with this?
>
> What is the system locale ?
> And what resource bunldes does your application use ? E.g.
> MyApplication_nl.properties and MyApplication.properties
>
> Thanks.
>
> Stan
>
> Martin Grigorov schreef op 2023-01-06 09:52:
>
> Hi,
>
> Here is the minimum for preloading the markup of any MarkupContainer:
>
> MarkupFactory markupFactory =
> Application.get().getMarkupSettings().getMarkupFactory();
> markupFactory.getMarkup(new AnyMarkupContainer(), false);
>
> AnyMarkupContainer could be a Page, Panel, Border, ..., any
> MarkupContainer
> impl.
> The Markup will be stored in the MarkupCache for the following needs.
>
> On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
> wrote:
>
> You can render components, not just pages
>
> According to the list
> You can create the list of all HTML files, find correspondent Java
> files
> and try to render them
>
> from mobile (sorry for typos ;)
>
> On Fri, Jan 6, 2023, 01:20 Chris Colman
> <ch...@stepaheadsoftware.com.invalid> wrote:
>
> In my case I have lots of modal forms (using Wicketstuff ModalX) that
> can be potentially opened by the user.
>
> Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> all of those modal forms as the page markup has no reference to the
> modal form contents/markup as it is using ModalX's generic modal dialog
> feature so there's no need to specify which form you wish to open in
> the
> markup of the page that will open it.
>
> I wonder if it would be possible to develop a 'parse all markup' that
> would pick up the markup for these forms as well, not just for the
> pages.
>
> On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
> 2:48 PM<st...@stantastic.nl> wrote:
>
> Hi Anna,
>
> I attempted this, and ended up with a method like this:
>
> private void preloadPages(Collection<Class<? extends
> IRequestablePage>>
>
> pages) {
> final Supplier<ISessionStore> oldSessionStoreProvider =
> getSessionStoreProvider();
>
> try {
> setSessionStoreProvider(() -> new MockSessionStore());
>
> final RequestCycle rc = createRequestCycle(new MockWebRequest(new
>
> Url()), new MockWebResponse());
> ThreadContext.setRequestCycle(rc);
>
> for (Class<? extends IRequestablePage> p : pages)
> ComponentRenderer.renderPage(new PageProvider(p));
> }
> finally {
> setSessionStoreProvider(oldSessionStoreProvider);
> }
> }
>
> Which I have not been able to test on more than one page yet, because
> I
>
> still need to implement something to render my other pages with an
> AuthenticatedWebSession. My login page's first load time has been
> reduced to about 10% of what it was though.
>
> I call that method from app.init().
>
> I have some doubts over Martin's claim that it is possible to do this
> on
>
> a different thread. As you may notice, I had to change the
> SessionStoreProvider to make this work. If I am correct that means
> that
>
> as long as this method runs, all sessions will be handled by the
> MockSessionStore.
>
> Stan
>
> Anna Eileen Eileen schreef op 2023-01-04 01:22:
>
> Dear Martin
>
> I don't know how to do "pre-touch", do you have any example?
>
> From: Martin Terra<ma...@koodaripalvelut.com>
> Date: Tuesday, January 3, 2023 at 11:37 PM
> To:stan@stantastic.nl <st...@stantastic.nl>
> Cc:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Re: Wicket on low end hardware
> Just a note, you don't need to make the startup "pre-touching"
> process
>
> a
> blocking one so that if a user were to interact with the app, they
> could do
> so while startup pretouch is doing its thing.
>
> And you could profile whether you want to do the pre-touch in single
> thread
> or multi-thraded.
>
> **
> Martin
>
> ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
>
> Thanks everyone. I did not expect the amount of feedback that I got.
> It
>
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this
> a
>
> criticism. I understand that not a lot of people run servlet
> containers
>
> on this kind of hardware nowadays.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent
> requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things
> considered,
>
> its performance did not impress me and that application really is
> super
>
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So
> I
>
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to
> live
>
> with that. Or we might switch from Tomcat to Jetty eventually. You
> may want to check the implementation of Wicket Native WebSocket
> module
>
> [1]
> WebSocket messages come in a TCP connection, i.e. there is no HTTP
> session/request/response.
> Because of that Wicket Native WebSocket stores the app name, session
> id,
>
> page id / resource name at the handshake time and later fetches /
> re-creates those to process any websocket message.
>
> I agree that the setup is not something simple. Loading a page may
depend
>> on external resources (like a user in your case, or an open DB
> connection,
>
>> ...).
>> Maybe you can simplify the preloading to just populate the Markup
>> cache
>> instead of fully render all pages.
>> IMO this deserves to be added to Wicket APIs as a helper or something!
>> 1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
> If anyone thinks I might be leaving some stuff on the table, I would
be
> open to hire someone to do some consulting work on this. Please get
in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> Anything in wicket can be preloaded, but as premature optimization
is
> evil, you should profile your application.
>
> If you do not have debug access to a real/simulated environment then
> the
> least you can do is make your own thread logger to log what the
threads
> are
> doing.
>
> **
> Martin
>
> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> kirjoitti:
>
> Hello
>
> Would you please describe your web application components? Database ?
> What services ran on the device?
>
> From:stan@stantastic.nl <st...@stantastic.nl>
> Date: Monday, January 2, 2023 at 5:23 AM
> To:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Wicket on low end hardware
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the
> first
> couple of page loads of the day. Just to be clear: I cannot really
> claim
> that my performance problems are all Wicket related. They may be, but
> they probably also are down to other underlying issues. A badly
> optimized database, or a badly configured servlet container come to
> mind...
>
> However, I was wondering if anyone has experience in using Wicket on
> low
> end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> For additional commands, e-mail:users-help@wicket.apache.org
--
Regards,
Chris Colman
*Feezily*,
A product of /Step Ahead/ *Software* Pty Ltd
Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
Ph: 02 9656 1278
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Jan 6, 2023 at 11:44 AM <st...@stantastic.nl> wrote:
> Hi all,
>
> As I was implementing markup caching by adding it directly to the
> MarkupCache, I found my gains weren't as big as I had expected (I guess
> premature optimization really is the root of all evil...). My tests
> using ComponentRenderer were much more promising.
>
> So I started to dig into this deeper and found that the first call to
> Localizer->getString() on our hardware takes between 1500 and 2000ms. I
> then started to investigate if this can also be preloaded but I am
> having a hard time coming up with something effective.
>
> Does anyone have experience with this?
>
What is the system locale ?
And what resource bunldes does your application use ? E.g.
MyApplication_nl.properties and MyApplication.properties
>
> Thanks.
>
> Stan
>
>
> Martin Grigorov schreef op 2023-01-06 09:52:
>
> > Hi,
> >
> > Here is the minimum for preloading the markup of any MarkupContainer:
> >
> > MarkupFactory markupFactory =
> > Application.get().getMarkupSettings().getMarkupFactory();
> > markupFactory.getMarkup(new AnyMarkupContainer(), false);
> >
> > AnyMarkupContainer could be a Page, Panel, Border, ..., any
> > MarkupContainer
> > impl.
> > The Markup will be stored in the MarkupCache for the following needs.
> >
> > On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
> > wrote:
> >
> > You can render components, not just pages
> >
> > According to the list
> > You can create the list of all HTML files, find correspondent Java
> > files
> > and try to render them
> >
> > from mobile (sorry for typos ;)
> >
> > On Fri, Jan 6, 2023, 01:20 Chris Colman
> > <ch...@stepaheadsoftware.com.invalid> wrote:
> >
> > In my case I have lots of modal forms (using Wicketstuff ModalX) that
> > can be potentially opened by the user.
> >
> > Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> > all of those modal forms as the page markup has no reference to the
> > modal form contents/markup as it is using ModalX's generic modal dialog
> > feature so there's no need to specify which form you wish to open in
> > the
> > markup of the page that will open it.
> >
> > I wonder if it would be possible to develop a 'parse all markup' that
> > would pick up the markup for these forms as well, not just for the
> > pages.
> >
> > On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
> > 2:48 PM<st...@stantastic.nl> wrote:
> >
> > Hi Anna,
> >
> > I attempted this, and ended up with a method like this:
> >
> > private void preloadPages(Collection<Class<? extends
> IRequestablePage>>
>
> > pages) {
> > final Supplier<ISessionStore> oldSessionStoreProvider =
> > getSessionStoreProvider();
> >
> > try {
> > setSessionStoreProvider(() -> new MockSessionStore());
> >
> > final RequestCycle rc = createRequestCycle(new
> MockWebRequest(new
>
> > Url()), new MockWebResponse());
> > ThreadContext.setRequestCycle(rc);
> >
> > for (Class<? extends IRequestablePage> p : pages)
> > ComponentRenderer.renderPage(new PageProvider(p));
> > }
> > finally {
> > setSessionStoreProvider(oldSessionStoreProvider);
> > }
> > }
> >
> > Which I have not been able to test on more than one page yet, because
> I
>
> > still need to implement something to render my other pages with an
> > AuthenticatedWebSession. My login page's first load time has been
> > reduced to about 10% of what it was though.
> >
> > I call that method from app.init().
> >
> > I have some doubts over Martin's claim that it is possible to do this
> on
>
> > a different thread. As you may notice, I had to change the
> > SessionStoreProvider to make this work. If I am correct that means
> that
>
> > as long as this method runs, all sessions will be handled by the
> > MockSessionStore.
> >
> > Stan
> >
> > Anna Eileen Eileen schreef op 2023-01-04 01:22:
> >
> > Dear Martin
> >
> > I don't know how to do "pre-touch", do you have any example?
> >
> > From: Martin Terra<ma...@koodaripalvelut.com>
> > Date: Tuesday, January 3, 2023 at 11:37 PM
> > To:stan@stantastic.nl <st...@stantastic.nl>
> > Cc:users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Re: Wicket on low end hardware
> > Just a note, you don't need to make the startup "pre-touching"
> process
>
> > a
> > blocking one so that if a user were to interact with the app, they
> > could do
> > so while startup pretouch is doing its thing.
> >
> > And you could profile whether you want to do the pre-touch in single
> > thread
> > or multi-thraded.
> >
> > **
> > Martin
> >
> > ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
> >
> > Thanks everyone. I did not expect the amount of feedback that I got.
> It
>
> > is much appreciated.
> >
> > I spent most of my day profiling with VisualVM and it strengthened by
> > beliefs that my problems do not appear to be related to anything but
> > Wicket combined with our dated hardware. Please do not consider this
> a
>
> > criticism. I understand that not a lot of people run servlet
> containers
>
> > on this kind of hardware nowadays.
> >
> > My database queries all run quickly and my domain classes are hardly
> > even touched when the system starts. Our rather simple login page -
> > which is stateless and does not query the database when the form is
> > empty - takes 5-15 seconds to load on the first try. Subsequent
> > requests
> > take about 40-120ms (browser caching disabled). Once logged in, the
> > other pages do not take as long, but they do feel sluggish until they
> > have been requested once.
> >
> > I tried to only load the quickstart example as Martijn suggested. It
> > starts more quickly than our own application but all things
> considered,
>
> > its performance did not impress me and that application really is
> super
>
> > simple. The first page load of the quickstart took about 2 seconds,
> > after that it normalized to about 30ms per request.
> >
> > When all pages have been loaded once, things are absolutely fine. So
> I
>
> > am considering Martin's approach of preloading components. That still
> > leaves me with the considerable startup time but we will learn to
> live
>
> > with that. Or we might switch from Tomcat to Jetty eventually.
> You may want to check the implementation of Wicket Native WebSocket
> module
>
> > [1]
> > WebSocket messages come in a TCP connection, i.e. there is no HTTP
> > session/request/response.
> > Because of that Wicket Native WebSocket stores the app name, session
> id,
>
> >> page id / resource name at the handshake time and later fetches /
> >> re-creates those to process any websocket message.
> >>
> >> I agree that the setup is not something simple. Loading a page may
> depend
>
> >> on external resources (like a user in your case, or an open DB
> > connection,
> >
> >> ...).
> >> Maybe you can simplify the preloading to just populate the Markup
> >> cache
> >> instead of fully render all pages.
> >> IMO this deserves to be added to Wicket APIs as a helper or something!
> >> 1.
>
>
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
>
> > If anyone thinks I might be leaving some stuff on the table, I would
> be
>
> > open to hire someone to do some consulting work on this. Please get
> in
>
> > touch with me if you are interested.
> >
> > Cheers.
> >
> > Stan
> >
> > Martin Terra schreef op 2023-01-02 04:29:
> >
> > Anything in wicket can be preloaded, but as premature optimization
> is
>
> > evil, you should profile your application.
> >
> > If you do not have debug access to a real/simulated environment then
> > the
> > least you can do is make your own thread logger to log what the
> threads
>
> > are
> > doing.
> >
> > **
> > Martin
> >
> > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > kirjoitti:
> >
> > Hello
> >
> > Would you please describe your web application components? Database ?
> > What services ran on the device?
> >
> > From:stan@stantastic.nl <st...@stantastic.nl>
> > Date: Monday, January 2, 2023 at 5:23 AM
> > To:users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Wicket on low end hardware
> >
> > Hi,
> >
> > My use case for Wicket is a quite unconventional one. I use it as the
> > framework for the web interface of an appliance that runs on low end
> > hardware. The appliance doesn't have gigabytes of memory to waste or
> > tens of CPU cores. It's more like Celeron powered hardware with maybe
> > one or two gigabytes of RAM.
> >
> > I general this all works and customers are happy once the device is
> > running. But I find that deployment is quite slow, and so are the
> > first
> > couple of page loads of the day. Just to be clear: I cannot really
> > claim
> > that my performance problems are all Wicket related. They may be, but
> > they probably also are down to other underlying issues. A badly
> > optimized database, or a badly configured servlet container come to
> > mind...
> >
> > However, I was wondering if anyone has experience in using Wicket on
> > low
> > end hardware. I would be very interested in how to optimize for this.
> >
> > Thanks,
> >
> > Stan
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail:users-help@wicket.apache.org
> --
> Regards,
>
> Chris Colman
> *Feezily*,
> A product of /Step Ahead/ *Software* Pty Ltd
> Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
> Ph: 02 9656 1278
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket on low end hardware
Posted by st...@stantastic.nl.
Hi all,
As I was implementing markup caching by adding it directly to the
MarkupCache, I found my gains weren't as big as I had expected (I guess
premature optimization really is the root of all evil...). My tests
using ComponentRenderer were much more promising.
So I started to dig into this deeper and found that the first call to
Localizer->getString() on our hardware takes between 1500 and 2000ms. I
then started to investigate if this can also be preloaded but I am
having a hard time coming up with something effective.
Does anyone have experience with this?
Thanks.
Stan
Martin Grigorov schreef op 2023-01-06 09:52:
> Hi,
>
> Here is the minimum for preloading the markup of any MarkupContainer:
>
> MarkupFactory markupFactory =
> Application.get().getMarkupSettings().getMarkupFactory();
> markupFactory.getMarkup(new AnyMarkupContainer(), false);
>
> AnyMarkupContainer could be a Page, Panel, Border, ..., any
> MarkupContainer
> impl.
> The Markup will be stored in the MarkupCache for the following needs.
>
> On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
> wrote:
>
> You can render components, not just pages
>
> According to the list
> You can create the list of all HTML files, find correspondent Java
> files
> and try to render them
>
> from mobile (sorry for typos ;)
>
> On Fri, Jan 6, 2023, 01:20 Chris Colman
> <ch...@stepaheadsoftware.com.invalid> wrote:
>
> In my case I have lots of modal forms (using Wicketstuff ModalX) that
> can be potentially opened by the user.
>
> Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> all of those modal forms as the page markup has no reference to the
> modal form contents/markup as it is using ModalX's generic modal dialog
> feature so there's no need to specify which form you wish to open in
> the
> markup of the page that will open it.
>
> I wonder if it would be possible to develop a 'parse all markup' that
> would pick up the markup for these forms as well, not just for the
> pages.
>
> On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
> 2:48 PM<st...@stantastic.nl> wrote:
>
> Hi Anna,
>
> I attempted this, and ended up with a method like this:
>
> private void preloadPages(Collection<Class<? extends
IRequestablePage>>
> pages) {
> final Supplier<ISessionStore> oldSessionStoreProvider =
> getSessionStoreProvider();
>
> try {
> setSessionStoreProvider(() -> new MockSessionStore());
>
> final RequestCycle rc = createRequestCycle(new
MockWebRequest(new
> Url()), new MockWebResponse());
> ThreadContext.setRequestCycle(rc);
>
> for (Class<? extends IRequestablePage> p : pages)
> ComponentRenderer.renderPage(new PageProvider(p));
> }
> finally {
> setSessionStoreProvider(oldSessionStoreProvider);
> }
> }
>
> Which I have not been able to test on more than one page yet, because
I
> still need to implement something to render my other pages with an
> AuthenticatedWebSession. My login page's first load time has been
> reduced to about 10% of what it was though.
>
> I call that method from app.init().
>
> I have some doubts over Martin's claim that it is possible to do this
on
> a different thread. As you may notice, I had to change the
> SessionStoreProvider to make this work. If I am correct that means
that
> as long as this method runs, all sessions will be handled by the
> MockSessionStore.
>
> Stan
>
> Anna Eileen Eileen schreef op 2023-01-04 01:22:
>
> Dear Martin
>
> I don't know how to do "pre-touch", do you have any example?
>
> From: Martin Terra<ma...@koodaripalvelut.com>
> Date: Tuesday, January 3, 2023 at 11:37 PM
> To:stan@stantastic.nl <st...@stantastic.nl>
> Cc:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Re: Wicket on low end hardware
> Just a note, you don't need to make the startup "pre-touching"
process
> a
> blocking one so that if a user were to interact with the app, they
> could do
> so while startup pretouch is doing its thing.
>
> And you could profile whether you want to do the pre-touch in single
> thread
> or multi-thraded.
>
> **
> Martin
>
> ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
>
> Thanks everyone. I did not expect the amount of feedback that I got.
It
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this
a
> criticism. I understand that not a lot of people run servlet
containers
> on this kind of hardware nowadays.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent
> requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things
considered,
> its performance did not impress me and that application really is
super
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So
I
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to
live
> with that. Or we might switch from Tomcat to Jetty eventually.
You may want to check the implementation of Wicket Native WebSocket
module
> [1]
> WebSocket messages come in a TCP connection, i.e. there is no HTTP
> session/request/response.
> Because of that Wicket Native WebSocket stores the app name, session
id,
>> page id / resource name at the handshake time and later fetches /
>> re-creates those to process any websocket message.
>>
>> I agree that the setup is not something simple. Loading a page may
depend
>> on external resources (like a user in your case, or an open DB
> connection,
>
>> ...).
>> Maybe you can simplify the preloading to just populate the Markup
>> cache
>> instead of fully render all pages.
>> IMO this deserves to be added to Wicket APIs as a helper or something!
>> 1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
> If anyone thinks I might be leaving some stuff on the table, I would
be
> open to hire someone to do some consulting work on this. Please get
in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> Anything in wicket can be preloaded, but as premature optimization
is
> evil, you should profile your application.
>
> If you do not have debug access to a real/simulated environment then
> the
> least you can do is make your own thread logger to log what the
threads
> are
> doing.
>
> **
> Martin
>
> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> kirjoitti:
>
> Hello
>
> Would you please describe your web application components? Database ?
> What services ran on the device?
>
> From:stan@stantastic.nl <st...@stantastic.nl>
> Date: Monday, January 2, 2023 at 5:23 AM
> To:users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Wicket on low end hardware
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the
> first
> couple of page loads of the day. Just to be clear: I cannot really
> claim
> that my performance problems are all Wicket related. They may be, but
> they probably also are down to other underlying issues. A badly
> optimized database, or a badly configured servlet container come to
> mind...
>
> However, I was wondering if anyone has experience in using Wicket on
> low
> end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> For additional commands, e-mail:users-help@wicket.apache.org
--
Regards,
Chris Colman
*Feezily*,
A product of /Step Ahead/ *Software* Pty Ltd
Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
Ph: 02 9656 1278
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Here is the minimum for preloading the markup of any MarkupContainer:
MarkupFactory markupFactory =
Application.get().getMarkupSettings().getMarkupFactory();
markupFactory.getMarkup(new AnyMarkupContainer(), false);
AnyMarkupContainer could be a Page, Panel, Border, ..., any MarkupContainer
impl.
The Markup will be stored in the MarkupCache for the following needs.
On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <so...@gmail.com>
wrote:
> You can render components, not just pages
>
> According to the list
> You can create the list of all HTML files, find correspondent Java files
> and try to render them
>
> from mobile (sorry for typos ;)
>
>
> On Fri, Jan 6, 2023, 01:20 Chris Colman
> <ch...@stepaheadsoftware.com.invalid> wrote:
>
> > In my case I have lots of modal forms (using Wicketstuff ModalX) that
> > can be potentially opened by the user.
> >
> > Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> > all of those modal forms as the page markup has no reference to the
> > modal form contents/markup as it is using ModalX's generic modal dialog
> > feature so there's no need to specify which form you wish to open in the
> > markup of the page that will open it.
> >
> > I wonder if it would be possible to develop a 'parse all markup' that
> > would pick up the markup for these forms as well, not just for the pages.
> >
> > On 5/01/2023 12:31 am, Martin Grigorov wrote:
> > > On Wed, Jan 4, 2023 at 2:48 PM<st...@stantastic.nl> wrote:
> > >
> > >> Hi Anna,
> > >>
> > >> I attempted this, and ended up with a method like this:
> > >>
> > >> private void preloadPages(Collection<Class<? extends
> IRequestablePage>>
> > >> pages) {
> > >> final Supplier<ISessionStore> oldSessionStoreProvider =
> > >> getSessionStoreProvider();
> > >>
> > >> try {
> > >> setSessionStoreProvider(() -> new MockSessionStore());
> > >>
> > >> final RequestCycle rc = createRequestCycle(new
> MockWebRequest(new
> > >> Url()), new MockWebResponse());
> > >> ThreadContext.setRequestCycle(rc);
> > >>
> > >> for (Class<? extends IRequestablePage> p : pages)
> > >> ComponentRenderer.renderPage(new PageProvider(p));
> > >> }
> > >> finally {
> > >> setSessionStoreProvider(oldSessionStoreProvider);
> > >> }
> > >> }
> > >>
> > >> Which I have not been able to test on more than one page yet, because
> I
> > >> still need to implement something to render my other pages with an
> > >> AuthenticatedWebSession. My login page's first load time has been
> > >> reduced to about 10% of what it was though.
> > >>
> > >> I call that method from app.init().
> > >>
> > >> I have some doubts over Martin's claim that it is possible to do this
> on
> > >> a different thread. As you may notice, I had to change the
> > >> SessionStoreProvider to make this work. If I am correct that means
> that
> > >> as long as this method runs, all sessions will be handled by the
> > >> MockSessionStore.
> > >>
> > >> Stan
> > >>
> > >>
> > >>
> > >>
> > >> Anna Eileen Eileen schreef op 2023-01-04 01:22:
> > >>
> > >>> Dear Martin
> > >>>
> > >>> I don't know how to do "pre-touch", do you have any example?
> > >>>
> > >>> From: Martin Terra<ma...@koodaripalvelut.com>
> > >>> Date: Tuesday, January 3, 2023 at 11:37 PM
> > >>> To:stan@stantastic.nl <st...@stantastic.nl>
> > >>> Cc:users@wicket.apache.org <us...@wicket.apache.org>
> > >>> Subject: Re: Wicket on low end hardware
> > >>> Just a note, you don't need to make the startup "pre-touching"
> process
> > >>> a
> > >>> blocking one so that if a user were to interact with the app, they
> > >>> could do
> > >>> so while startup pretouch is doing its thing.
> > >>>
> > >>> And you could profile whether you want to do the pre-touch in single
> > >>> thread
> > >>> or multi-thraded.
> > >>>
> > >>> **
> > >>> Martin
> > >>>
> > >>> ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
> > >>>
> > >>> Thanks everyone. I did not expect the amount of feedback that I got.
> It
> > >>> is much appreciated.
> > >>>
> > >>> I spent most of my day profiling with VisualVM and it strengthened by
> > >>> beliefs that my problems do not appear to be related to anything but
> > >>> Wicket combined with our dated hardware. Please do not consider this
> a
> > >>> criticism. I understand that not a lot of people run servlet
> containers
> > >>> on this kind of hardware nowadays.
> > >>>
> > >>> My database queries all run quickly and my domain classes are hardly
> > >>> even touched when the system starts. Our rather simple login page -
> > >>> which is stateless and does not query the database when the form is
> > >>> empty - takes 5-15 seconds to load on the first try. Subsequent
> > >>> requests
> > >>> take about 40-120ms (browser caching disabled). Once logged in, the
> > >>> other pages do not take as long, but they do feel sluggish until they
> > >>> have been requested once.
> > >>>
> > >>> I tried to only load the quickstart example as Martijn suggested. It
> > >>> starts more quickly than our own application but all things
> considered,
> > >>> its performance did not impress me and that application really is
> super
> > >>> simple. The first page load of the quickstart took about 2 seconds,
> > >>> after that it normalized to about 30ms per request.
> > >>>
> > >>> When all pages have been loaded once, things are absolutely fine. So
> I
> > >>> am considering Martin's approach of preloading components. That still
> > >>> leaves me with the considerable startup time but we will learn to
> live
> > >>> with that. Or we might switch from Tomcat to Jetty eventually.
> > > You may want to check the implementation of Wicket Native WebSocket
> > module
> > > [1]
> > > WebSocket messages come in a TCP connection, i.e. there is no HTTP
> > > session/request/response.
> > > Because of that Wicket Native WebSocket stores the app name, session
> id,
> > > page id / resource name at the handshake time and later fetches /
> > > re-creates those to process any websocket message.
> > >
> > > I agree that the setup is not something simple. Loading a page may
> depend
> > > on external resources (like a user in your case, or an open DB
> > connection,
> > > ...).
> > > Maybe you can simplify the preloading to just populate the Markup cache
> > > instead of fully render all pages.
> > > IMO this deserves to be added to Wicket APIs as a helper or something!
> > > 1.
> > >
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
> > >
> > >
> > >
> > >>> If anyone thinks I might be leaving some stuff on the table, I would
> be
> > >>> open to hire someone to do some consulting work on this. Please get
> in
> > >>> touch with me if you are interested.
> > >>>
> > >>> Cheers.
> > >>>
> > >>> Stan
> > >>>
> > >>> Martin Terra schreef op 2023-01-02 04:29:
> > >>>
> > >>> Anything in wicket can be preloaded, but as premature optimization
> is
> > >>> evil, you should profile your application.
> > >>>
> > >>> If you do not have debug access to a real/simulated environment then
> > >>> the
> > >>> least you can do is make your own thread logger to log what the
> threads
> > >>> are
> > >>> doing.
> > >>>
> > >>> **
> > >>> Martin
> > >>>
> > >>> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > >>> kirjoitti:
> > >>>
> > >>> Hello
> > >>>
> > >>> Would you please describe your web application components? Database ?
> > >>> What services ran on the device?
> > >>>
> > >>> From:stan@stantastic.nl <st...@stantastic.nl>
> > >>> Date: Monday, January 2, 2023 at 5:23 AM
> > >>> To:users@wicket.apache.org <us...@wicket.apache.org>
> > >>> Subject: Wicket on low end hardware
> > >>>
> > >>> Hi,
> > >>>
> > >>> My use case for Wicket is a quite unconventional one. I use it as the
> > >>> framework for the web interface of an appliance that runs on low end
> > >>> hardware. The appliance doesn't have gigabytes of memory to waste or
> > >>> tens of CPU cores. It's more like Celeron powered hardware with maybe
> > >>> one or two gigabytes of RAM.
> > >>>
> > >>> I general this all works and customers are happy once the device is
> > >>> running. But I find that deployment is quite slow, and so are the
> > >>> first
> > >>> couple of page loads of the day. Just to be clear: I cannot really
> > >>> claim
> > >>> that my performance problems are all Wicket related. They may be, but
> > >>> they probably also are down to other underlying issues. A badly
> > >>> optimized database, or a badly configured servlet container come to
> > >>> mind...
> > >>>
> > >>> However, I was wondering if anyone has experience in using Wicket on
> > >>> low
> > >>> end hardware. I would be very interested in how to optimize for this.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Stan
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail:users-help@wicket.apache.org
> > >>
> > >>
> > --
> > Regards,
> >
> > Chris Colman
> > *Feezily*,
> > A product of /Step Ahead/ *Software* Pty Ltd
> > Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
> > Ph: 02 9656 1278
>
Re: Wicket on low end hardware
Posted by Maxim Solodovnik <so...@gmail.com>.
You can render components, not just pages
According to the list
You can create the list of all HTML files, find correspondent Java files
and try to render them
from mobile (sorry for typos ;)
On Fri, Jan 6, 2023, 01:20 Chris Colman
<ch...@stepaheadsoftware.com.invalid> wrote:
> In my case I have lots of modal forms (using Wicketstuff ModalX) that
> can be potentially opened by the user.
>
> Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
> all of those modal forms as the page markup has no reference to the
> modal form contents/markup as it is using ModalX's generic modal dialog
> feature so there's no need to specify which form you wish to open in the
> markup of the page that will open it.
>
> I wonder if it would be possible to develop a 'parse all markup' that
> would pick up the markup for these forms as well, not just for the pages.
>
> On 5/01/2023 12:31 am, Martin Grigorov wrote:
> > On Wed, Jan 4, 2023 at 2:48 PM<st...@stantastic.nl> wrote:
> >
> >> Hi Anna,
> >>
> >> I attempted this, and ended up with a method like this:
> >>
> >> private void preloadPages(Collection<Class<? extends IRequestablePage>>
> >> pages) {
> >> final Supplier<ISessionStore> oldSessionStoreProvider =
> >> getSessionStoreProvider();
> >>
> >> try {
> >> setSessionStoreProvider(() -> new MockSessionStore());
> >>
> >> final RequestCycle rc = createRequestCycle(new MockWebRequest(new
> >> Url()), new MockWebResponse());
> >> ThreadContext.setRequestCycle(rc);
> >>
> >> for (Class<? extends IRequestablePage> p : pages)
> >> ComponentRenderer.renderPage(new PageProvider(p));
> >> }
> >> finally {
> >> setSessionStoreProvider(oldSessionStoreProvider);
> >> }
> >> }
> >>
> >> Which I have not been able to test on more than one page yet, because I
> >> still need to implement something to render my other pages with an
> >> AuthenticatedWebSession. My login page's first load time has been
> >> reduced to about 10% of what it was though.
> >>
> >> I call that method from app.init().
> >>
> >> I have some doubts over Martin's claim that it is possible to do this on
> >> a different thread. As you may notice, I had to change the
> >> SessionStoreProvider to make this work. If I am correct that means that
> >> as long as this method runs, all sessions will be handled by the
> >> MockSessionStore.
> >>
> >> Stan
> >>
> >>
> >>
> >>
> >> Anna Eileen Eileen schreef op 2023-01-04 01:22:
> >>
> >>> Dear Martin
> >>>
> >>> I don't know how to do "pre-touch", do you have any example?
> >>>
> >>> From: Martin Terra<ma...@koodaripalvelut.com>
> >>> Date: Tuesday, January 3, 2023 at 11:37 PM
> >>> To:stan@stantastic.nl <st...@stantastic.nl>
> >>> Cc:users@wicket.apache.org <us...@wicket.apache.org>
> >>> Subject: Re: Wicket on low end hardware
> >>> Just a note, you don't need to make the startup "pre-touching" process
> >>> a
> >>> blocking one so that if a user were to interact with the app, they
> >>> could do
> >>> so while startup pretouch is doing its thing.
> >>>
> >>> And you could profile whether you want to do the pre-touch in single
> >>> thread
> >>> or multi-thraded.
> >>>
> >>> **
> >>> Martin
> >>>
> >>> ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
> >>>
> >>> Thanks everyone. I did not expect the amount of feedback that I got. It
> >>> is much appreciated.
> >>>
> >>> I spent most of my day profiling with VisualVM and it strengthened by
> >>> beliefs that my problems do not appear to be related to anything but
> >>> Wicket combined with our dated hardware. Please do not consider this a
> >>> criticism. I understand that not a lot of people run servlet containers
> >>> on this kind of hardware nowadays.
> >>>
> >>> My database queries all run quickly and my domain classes are hardly
> >>> even touched when the system starts. Our rather simple login page -
> >>> which is stateless and does not query the database when the form is
> >>> empty - takes 5-15 seconds to load on the first try. Subsequent
> >>> requests
> >>> take about 40-120ms (browser caching disabled). Once logged in, the
> >>> other pages do not take as long, but they do feel sluggish until they
> >>> have been requested once.
> >>>
> >>> I tried to only load the quickstart example as Martijn suggested. It
> >>> starts more quickly than our own application but all things considered,
> >>> its performance did not impress me and that application really is super
> >>> simple. The first page load of the quickstart took about 2 seconds,
> >>> after that it normalized to about 30ms per request.
> >>>
> >>> When all pages have been loaded once, things are absolutely fine. So I
> >>> am considering Martin's approach of preloading components. That still
> >>> leaves me with the considerable startup time but we will learn to live
> >>> with that. Or we might switch from Tomcat to Jetty eventually.
> > You may want to check the implementation of Wicket Native WebSocket
> module
> > [1]
> > WebSocket messages come in a TCP connection, i.e. there is no HTTP
> > session/request/response.
> > Because of that Wicket Native WebSocket stores the app name, session id,
> > page id / resource name at the handshake time and later fetches /
> > re-creates those to process any websocket message.
> >
> > I agree that the setup is not something simple. Loading a page may depend
> > on external resources (like a user in your case, or an open DB
> connection,
> > ...).
> > Maybe you can simplify the preloading to just populate the Markup cache
> > instead of fully render all pages.
> > IMO this deserves to be added to Wicket APIs as a helper or something!
> > 1.
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
> >
> >
> >
> >>> If anyone thinks I might be leaving some stuff on the table, I would be
> >>> open to hire someone to do some consulting work on this. Please get in
> >>> touch with me if you are interested.
> >>>
> >>> Cheers.
> >>>
> >>> Stan
> >>>
> >>> Martin Terra schreef op 2023-01-02 04:29:
> >>>
> >>> Anything in wicket can be preloaded, but as premature optimization is
> >>> evil, you should profile your application.
> >>>
> >>> If you do not have debug access to a real/simulated environment then
> >>> the
> >>> least you can do is make your own thread logger to log what the threads
> >>> are
> >>> doing.
> >>>
> >>> **
> >>> Martin
> >>>
> >>> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> >>> kirjoitti:
> >>>
> >>> Hello
> >>>
> >>> Would you please describe your web application components? Database ?
> >>> What services ran on the device?
> >>>
> >>> From:stan@stantastic.nl <st...@stantastic.nl>
> >>> Date: Monday, January 2, 2023 at 5:23 AM
> >>> To:users@wicket.apache.org <us...@wicket.apache.org>
> >>> Subject: Wicket on low end hardware
> >>>
> >>> Hi,
> >>>
> >>> My use case for Wicket is a quite unconventional one. I use it as the
> >>> framework for the web interface of an appliance that runs on low end
> >>> hardware. The appliance doesn't have gigabytes of memory to waste or
> >>> tens of CPU cores. It's more like Celeron powered hardware with maybe
> >>> one or two gigabytes of RAM.
> >>>
> >>> I general this all works and customers are happy once the device is
> >>> running. But I find that deployment is quite slow, and so are the
> >>> first
> >>> couple of page loads of the day. Just to be clear: I cannot really
> >>> claim
> >>> that my performance problems are all Wicket related. They may be, but
> >>> they probably also are down to other underlying issues. A badly
> >>> optimized database, or a badly configured servlet container come to
> >>> mind...
> >>>
> >>> However, I was wondering if anyone has experience in using Wicket on
> >>> low
> >>> end hardware. I would be very interested in how to optimize for this.
> >>>
> >>> Thanks,
> >>>
> >>> Stan
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail:users-help@wicket.apache.org
> >>
> >>
> --
> Regards,
>
> Chris Colman
> *Feezily*,
> A product of /Step Ahead/ *Software* Pty Ltd
> Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
> Ph: 02 9656 1278
Re: Wicket on low end hardware
Posted by Chris Colman <ch...@stepaheadsoftware.com.INVALID>.
In my case I have lots of modal forms (using Wicketstuff ModalX) that
can be potentially opened by the user.
Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
all of those modal forms as the page markup has no reference to the
modal form contents/markup as it is using ModalX's generic modal dialog
feature so there's no need to specify which form you wish to open in the
markup of the page that will open it.
I wonder if it would be possible to develop a 'parse all markup' that
would pick up the markup for these forms as well, not just for the pages.
On 5/01/2023 12:31 am, Martin Grigorov wrote:
> On Wed, Jan 4, 2023 at 2:48 PM<st...@stantastic.nl> wrote:
>
>> Hi Anna,
>>
>> I attempted this, and ended up with a method like this:
>>
>> private void preloadPages(Collection<Class<? extends IRequestablePage>>
>> pages) {
>> final Supplier<ISessionStore> oldSessionStoreProvider =
>> getSessionStoreProvider();
>>
>> try {
>> setSessionStoreProvider(() -> new MockSessionStore());
>>
>> final RequestCycle rc = createRequestCycle(new MockWebRequest(new
>> Url()), new MockWebResponse());
>> ThreadContext.setRequestCycle(rc);
>>
>> for (Class<? extends IRequestablePage> p : pages)
>> ComponentRenderer.renderPage(new PageProvider(p));
>> }
>> finally {
>> setSessionStoreProvider(oldSessionStoreProvider);
>> }
>> }
>>
>> Which I have not been able to test on more than one page yet, because I
>> still need to implement something to render my other pages with an
>> AuthenticatedWebSession. My login page's first load time has been
>> reduced to about 10% of what it was though.
>>
>> I call that method from app.init().
>>
>> I have some doubts over Martin's claim that it is possible to do this on
>> a different thread. As you may notice, I had to change the
>> SessionStoreProvider to make this work. If I am correct that means that
>> as long as this method runs, all sessions will be handled by the
>> MockSessionStore.
>>
>> Stan
>>
>>
>>
>>
>> Anna Eileen Eileen schreef op 2023-01-04 01:22:
>>
>>> Dear Martin
>>>
>>> I don't know how to do "pre-touch", do you have any example?
>>>
>>> From: Martin Terra<ma...@koodaripalvelut.com>
>>> Date: Tuesday, January 3, 2023 at 11:37 PM
>>> To:stan@stantastic.nl <st...@stantastic.nl>
>>> Cc:users@wicket.apache.org <us...@wicket.apache.org>
>>> Subject: Re: Wicket on low end hardware
>>> Just a note, you don't need to make the startup "pre-touching" process
>>> a
>>> blocking one so that if a user were to interact with the app, they
>>> could do
>>> so while startup pretouch is doing its thing.
>>>
>>> And you could profile whether you want to do the pre-touch in single
>>> thread
>>> or multi-thraded.
>>>
>>> **
>>> Martin
>>>
>>> ti 3. tammik. 2023 klo 16.58stan@stantastic.nl kirjoitti:
>>>
>>> Thanks everyone. I did not expect the amount of feedback that I got. It
>>> is much appreciated.
>>>
>>> I spent most of my day profiling with VisualVM and it strengthened by
>>> beliefs that my problems do not appear to be related to anything but
>>> Wicket combined with our dated hardware. Please do not consider this a
>>> criticism. I understand that not a lot of people run servlet containers
>>> on this kind of hardware nowadays.
>>>
>>> My database queries all run quickly and my domain classes are hardly
>>> even touched when the system starts. Our rather simple login page -
>>> which is stateless and does not query the database when the form is
>>> empty - takes 5-15 seconds to load on the first try. Subsequent
>>> requests
>>> take about 40-120ms (browser caching disabled). Once logged in, the
>>> other pages do not take as long, but they do feel sluggish until they
>>> have been requested once.
>>>
>>> I tried to only load the quickstart example as Martijn suggested. It
>>> starts more quickly than our own application but all things considered,
>>> its performance did not impress me and that application really is super
>>> simple. The first page load of the quickstart took about 2 seconds,
>>> after that it normalized to about 30ms per request.
>>>
>>> When all pages have been loaded once, things are absolutely fine. So I
>>> am considering Martin's approach of preloading components. That still
>>> leaves me with the considerable startup time but we will learn to live
>>> with that. Or we might switch from Tomcat to Jetty eventually.
> You may want to check the implementation of Wicket Native WebSocket module
> [1]
> WebSocket messages come in a TCP connection, i.e. there is no HTTP
> session/request/response.
> Because of that Wicket Native WebSocket stores the app name, session id,
> page id / resource name at the handshake time and later fetches /
> re-creates those to process any websocket message.
>
> I agree that the setup is not something simple. Loading a page may depend
> on external resources (like a user in your case, or an open DB connection,
> ...).
> Maybe you can simplify the preloading to just populate the Markup cache
> instead of fully render all pages.
> IMO this deserves to be added to Wicket APIs as a helper or something!
> 1.
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
>
>
>
>>> If anyone thinks I might be leaving some stuff on the table, I would be
>>> open to hire someone to do some consulting work on this. Please get in
>>> touch with me if you are interested.
>>>
>>> Cheers.
>>>
>>> Stan
>>>
>>> Martin Terra schreef op 2023-01-02 04:29:
>>>
>>> Anything in wicket can be preloaded, but as premature optimization is
>>> evil, you should profile your application.
>>>
>>> If you do not have debug access to a real/simulated environment then
>>> the
>>> least you can do is make your own thread logger to log what the threads
>>> are
>>> doing.
>>>
>>> **
>>> Martin
>>>
>>> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
>>> kirjoitti:
>>>
>>> Hello
>>>
>>> Would you please describe your web application components? Database ?
>>> What services ran on the device?
>>>
>>> From:stan@stantastic.nl <st...@stantastic.nl>
>>> Date: Monday, January 2, 2023 at 5:23 AM
>>> To:users@wicket.apache.org <us...@wicket.apache.org>
>>> Subject: Wicket on low end hardware
>>>
>>> Hi,
>>>
>>> My use case for Wicket is a quite unconventional one. I use it as the
>>> framework for the web interface of an appliance that runs on low end
>>> hardware. The appliance doesn't have gigabytes of memory to waste or
>>> tens of CPU cores. It's more like Celeron powered hardware with maybe
>>> one or two gigabytes of RAM.
>>>
>>> I general this all works and customers are happy once the device is
>>> running. But I find that deployment is quite slow, and so are the
>>> first
>>> couple of page loads of the day. Just to be clear: I cannot really
>>> claim
>>> that my performance problems are all Wicket related. They may be, but
>>> they probably also are down to other underlying issues. A badly
>>> optimized database, or a badly configured servlet container come to
>>> mind...
>>>
>>> However, I was wondering if anyone has experience in using Wicket on
>>> low
>>> end hardware. I would be very interested in how to optimize for this.
>>>
>>> Thanks,
>>>
>>> Stan
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail:users-help@wicket.apache.org
>>
>>
--
Regards,
Chris Colman
*Feezily*,
A product of /Step Ahead/ *Software* Pty Ltd
Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
Ph: 02 9656 1278
Re: Wicket on low end hardware
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jan 4, 2023 at 2:48 PM <st...@stantastic.nl> wrote:
> Hi Anna,
>
> I attempted this, and ended up with a method like this:
>
> private void preloadPages(Collection<Class<? extends IRequestablePage>>
> pages) {
> final Supplier<ISessionStore> oldSessionStoreProvider =
> getSessionStoreProvider();
>
> try {
> setSessionStoreProvider(() -> new MockSessionStore());
>
> final RequestCycle rc = createRequestCycle(new MockWebRequest(new
> Url()), new MockWebResponse());
> ThreadContext.setRequestCycle(rc);
>
> for (Class<? extends IRequestablePage> p : pages)
> ComponentRenderer.renderPage(new PageProvider(p));
> }
> finally {
> setSessionStoreProvider(oldSessionStoreProvider);
> }
> }
>
> Which I have not been able to test on more than one page yet, because I
> still need to implement something to render my other pages with an
> AuthenticatedWebSession. My login page's first load time has been
> reduced to about 10% of what it was though.
>
> I call that method from app.init().
>
> I have some doubts over Martin's claim that it is possible to do this on
> a different thread. As you may notice, I had to change the
> SessionStoreProvider to make this work. If I am correct that means that
> as long as this method runs, all sessions will be handled by the
> MockSessionStore.
>
> Stan
>
>
>
>
> Anna Eileen Eileen schreef op 2023-01-04 01:22:
>
> > Dear Martin
> >
> > I don't know how to do "pre-touch", do you have any example?
> >
> > From: Martin Terra <ma...@koodaripalvelut.com>
> > Date: Tuesday, January 3, 2023 at 11:37 PM
> > To: stan@stantastic.nl <st...@stantastic.nl>
> > Cc: users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Re: Wicket on low end hardware
> > Just a note, you don't need to make the startup "pre-touching" process
> > a
> > blocking one so that if a user were to interact with the app, they
> > could do
> > so while startup pretouch is doing its thing.
> >
> > And you could profile whether you want to do the pre-touch in single
> > thread
> > or multi-thraded.
> >
> > **
> > Martin
> >
> > ti 3. tammik. 2023 klo 16.58 stan@stantastic.nl kirjoitti:
> >
> > Thanks everyone. I did not expect the amount of feedback that I got. It
> > is much appreciated.
> >
> > I spent most of my day profiling with VisualVM and it strengthened by
> > beliefs that my problems do not appear to be related to anything but
> > Wicket combined with our dated hardware. Please do not consider this a
> > criticism. I understand that not a lot of people run servlet containers
> > on this kind of hardware nowadays.
> >
> > My database queries all run quickly and my domain classes are hardly
> > even touched when the system starts. Our rather simple login page -
> > which is stateless and does not query the database when the form is
> > empty - takes 5-15 seconds to load on the first try. Subsequent
> > requests
> > take about 40-120ms (browser caching disabled). Once logged in, the
> > other pages do not take as long, but they do feel sluggish until they
> > have been requested once.
> >
> > I tried to only load the quickstart example as Martijn suggested. It
> > starts more quickly than our own application but all things considered,
> > its performance did not impress me and that application really is super
> > simple. The first page load of the quickstart took about 2 seconds,
> > after that it normalized to about 30ms per request.
> >
> > When all pages have been loaded once, things are absolutely fine. So I
> > am considering Martin's approach of preloading components. That still
> > leaves me with the considerable startup time but we will learn to live
> > with that. Or we might switch from Tomcat to Jetty eventually.
>
You may want to check the implementation of Wicket Native WebSocket module
[1]
WebSocket messages come in a TCP connection, i.e. there is no HTTP
session/request/response.
Because of that Wicket Native WebSocket stores the app name, session id,
page id / resource name at the handshake time and later fetches /
re-creates those to process any websocket message.
I agree that the setup is not something simple. Loading a page may depend
on external resources (like a user in your case, or an open DB connection,
...).
Maybe you can simplify the preloading to just populate the Markup cache
instead of fully render all pages.
IMO this deserves to be added to Wicket APIs as a helper or something!
1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
> >
> > If anyone thinks I might be leaving some stuff on the table, I would be
> > open to hire someone to do some consulting work on this. Please get in
> > touch with me if you are interested.
> >
> > Cheers.
> >
> > Stan
> >
> > Martin Terra schreef op 2023-01-02 04:29:
> >
> > Anything in wicket can be preloaded, but as premature optimization is
> > evil, you should profile your application.
> >
> > If you do not have debug access to a real/simulated environment then
> > the
> > least you can do is make your own thread logger to log what the threads
> > are
> > doing.
> >
> > **
> > Martin
> >
> > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > kirjoitti:
> >
> > Hello
> >
> > Would you please describe your web application components? Database ?
> > What services ran on the device?
> >
> > From: stan@stantastic.nl <st...@stantastic.nl>
> > Date: Monday, January 2, 2023 at 5:23 AM
> > To: users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Wicket on low end hardware
> >
> > Hi,
> >
> > My use case for Wicket is a quite unconventional one. I use it as the
> > framework for the web interface of an appliance that runs on low end
> > hardware. The appliance doesn't have gigabytes of memory to waste or
> > tens of CPU cores. It's more like Celeron powered hardware with maybe
> > one or two gigabytes of RAM.
> >
> > I general this all works and customers are happy once the device is
> > running. But I find that deployment is quite slow, and so are the
> > first
> > couple of page loads of the day. Just to be clear: I cannot really
> > claim
> > that my performance problems are all Wicket related. They may be, but
> > they probably also are down to other underlying issues. A badly
> > optimized database, or a badly configured servlet container come to
> > mind...
> >
> > However, I was wondering if anyone has experience in using Wicket on
> > low
> > end hardware. I would be very interested in how to optimize for this.
> >
> > Thanks,
> >
> > Stan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket on low end hardware
Posted by st...@stantastic.nl.
Hi Anna,
I attempted this, and ended up with a method like this:
private void preloadPages(Collection<Class<? extends IRequestablePage>>
pages) {
final Supplier<ISessionStore> oldSessionStoreProvider =
getSessionStoreProvider();
try {
setSessionStoreProvider(() -> new MockSessionStore());
final RequestCycle rc = createRequestCycle(new MockWebRequest(new
Url()), new MockWebResponse());
ThreadContext.setRequestCycle(rc);
for (Class<? extends IRequestablePage> p : pages)
ComponentRenderer.renderPage(new PageProvider(p));
}
finally {
setSessionStoreProvider(oldSessionStoreProvider);
}
}
Which I have not been able to test on more than one page yet, because I
still need to implement something to render my other pages with an
AuthenticatedWebSession. My login page's first load time has been
reduced to about 10% of what it was though.
I call that method from app.init().
I have some doubts over Martin's claim that it is possible to do this on
a different thread. As you may notice, I had to change the
SessionStoreProvider to make this work. If I am correct that means that
as long as this method runs, all sessions will be handled by the
MockSessionStore.
Stan
Anna Eileen Eileen schreef op 2023-01-04 01:22:
> Dear Martin
>
> I don't know how to do "pre-touch", do you have any example?
>
> From: Martin Terra <ma...@koodaripalvelut.com>
> Date: Tuesday, January 3, 2023 at 11:37 PM
> To: stan@stantastic.nl <st...@stantastic.nl>
> Cc: users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Re: Wicket on low end hardware
> Just a note, you don't need to make the startup "pre-touching" process
> a
> blocking one so that if a user were to interact with the app, they
> could do
> so while startup pretouch is doing its thing.
>
> And you could profile whether you want to do the pre-touch in single
> thread
> or multi-thraded.
>
> **
> Martin
>
> ti 3. tammik. 2023 klo 16.58 stan@stantastic.nl kirjoitti:
>
> Thanks everyone. I did not expect the amount of feedback that I got. It
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this a
> criticism. I understand that not a lot of people run servlet containers
> on this kind of hardware nowadays.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent
> requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things considered,
> its performance did not impress me and that application really is super
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So I
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to live
> with that. Or we might switch from Tomcat to Jetty eventually.
>
> If anyone thinks I might be leaving some stuff on the table, I would be
> open to hire someone to do some consulting work on this. Please get in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> Anything in wicket can be preloaded, but as premature optimization is
> evil, you should profile your application.
>
> If you do not have debug access to a real/simulated environment then
> the
> least you can do is make your own thread logger to log what the threads
> are
> doing.
>
> **
> Martin
>
> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> kirjoitti:
>
> Hello
>
> Would you please describe your web application components? Database ?
> What services ran on the device?
>
> From: stan@stantastic.nl <st...@stantastic.nl>
> Date: Monday, January 2, 2023 at 5:23 AM
> To: users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Wicket on low end hardware
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the
> first
> couple of page loads of the day. Just to be clear: I cannot really
> claim
> that my performance problems are all Wicket related. They may be, but
> they probably also are down to other underlying issues. A badly
> optimized database, or a badly configured servlet container come to
> mind...
>
> However, I was wondering if anyone has experience in using Wicket on
> low
> end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by Anna Eileen Eileen <sh...@gmail.com>.
Dear Martin
I don’t know how to do “pre-touch”, do you have any example?
From: Martin Terra <ma...@koodaripalvelut.com>
Date: Tuesday, January 3, 2023 at 11:37 PM
To: stan@stantastic.nl <st...@stantastic.nl>
Cc: users@wicket.apache.org <us...@wicket.apache.org>
Subject: Re: Wicket on low end hardware
Just a note, you don't need to make the startup "pre-touching" process a
blocking one so that if a user were to interact with the app, they could do
so while startup pretouch is doing its thing.
And you could profile whether you want to do the pre-touch in single thread
or multi-thraded.
**
Martin
ti 3. tammik. 2023 klo 16.58 stan@stantastic.nl kirjoitti:
> Thanks everyone. I did not expect the amount of feedback that I got. It
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this a
> criticism. I understand that not a lot of people run servlet containers
> on this kind of hardware nowadays.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things considered,
> its performance did not impress me and that application really is super
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So I
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to live
> with that. Or we might switch from Tomcat to Jetty eventually.
>
> If anyone thinks I might be leaving some stuff on the table, I would be
> open to hire someone to do some consulting work on this. Please get in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> > Anything in wicket can be preloaded, but as premature optimization is
> > evil, you should profile your application.
> >
> > If you do not have debug access to a real/simulated environment then
> > the
> > least you can do is make your own thread logger to log what the threads
> > are
> > doing.
> >
> > **
> > Martin
> >
> > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > kirjoitti:
> >
> >> Hello
> >>
> >> Would you please describe your web application components? Database ?
> >> What services ran on the device?
> >>
> >> From: stan@stantastic.nl <st...@stantastic.nl>
> >> Date: Monday, January 2, 2023 at 5:23 AM
> >> To: users@wicket.apache.org <us...@wicket.apache.org>
> >> Subject: Wicket on low end hardware
> >>
> >> Hi,
> >>
> >> My use case for Wicket is a quite unconventional one. I use it as the
> >> framework for the web interface of an appliance that runs on low end
> >> hardware. The appliance doesn't have gigabytes of memory to waste or
> >> tens of CPU cores. It's more like Celeron powered hardware with maybe
> >> one or two gigabytes of RAM.
> >>
> >> I general this all works and customers are happy once the device is
> >> running. But I find that deployment is quite slow, and so are the
> >> first
> >> couple of page loads of the day. Just to be clear: I cannot really
> >> claim
> >> that my performance problems are all Wicket related. They may be, but
> >> they probably also are down to other underlying issues. A badly
> >> optimized database, or a badly configured servlet container come to
> >> mind...
> >>
> >> However, I was wondering if anyone has experience in using Wicket on
> >> low
> >> end hardware. I would be very interested in how to optimize for this.
> >>
> >> Thanks,
> >>
> >> Stan
>
Re: Wicket on low end hardware
Posted by Martin Terra <ma...@koodaripalvelut.com>.
Just a note, you don't need to make the startup "pre-touching" process a
blocking one so that if a user were to interact with the app, they could do
so while startup pretouch is doing its thing.
And you could profile whether you want to do the pre-touch in single thread
or multi-thraded.
**
Martin
ti 3. tammik. 2023 klo 16.58 stan@stantastic.nl kirjoitti:
> Thanks everyone. I did not expect the amount of feedback that I got. It
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this a
> criticism. I understand that not a lot of people run servlet containers
> on this kind of hardware nowadays.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things considered,
> its performance did not impress me and that application really is super
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So I
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to live
> with that. Or we might switch from Tomcat to Jetty eventually.
>
> If anyone thinks I might be leaving some stuff on the table, I would be
> open to hire someone to do some consulting work on this. Please get in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> > Anything in wicket can be preloaded, but as premature optimization is
> > evil, you should profile your application.
> >
> > If you do not have debug access to a real/simulated environment then
> > the
> > least you can do is make your own thread logger to log what the threads
> > are
> > doing.
> >
> > **
> > Martin
> >
> > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > kirjoitti:
> >
> >> Hello
> >>
> >> Would you please describe your web application components? Database ?
> >> What services ran on the device?
> >>
> >> From: stan@stantastic.nl <st...@stantastic.nl>
> >> Date: Monday, January 2, 2023 at 5:23 AM
> >> To: users@wicket.apache.org <us...@wicket.apache.org>
> >> Subject: Wicket on low end hardware
> >>
> >> Hi,
> >>
> >> My use case for Wicket is a quite unconventional one. I use it as the
> >> framework for the web interface of an appliance that runs on low end
> >> hardware. The appliance doesn't have gigabytes of memory to waste or
> >> tens of CPU cores. It's more like Celeron powered hardware with maybe
> >> one or two gigabytes of RAM.
> >>
> >> I general this all works and customers are happy once the device is
> >> running. But I find that deployment is quite slow, and so are the
> >> first
> >> couple of page loads of the day. Just to be clear: I cannot really
> >> claim
> >> that my performance problems are all Wicket related. They may be, but
> >> they probably also are down to other underlying issues. A badly
> >> optimized database, or a badly configured servlet container come to
> >> mind...
> >>
> >> However, I was wondering if anyone has experience in using Wicket on
> >> low
> >> end hardware. I would be very interested in how to optimize for this.
> >>
> >> Thanks,
> >>
> >> Stan
>
Re: Wicket on low end hardware
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Jan 3, 2023 at 4:58 PM <st...@stantastic.nl> wrote:
> Thanks everyone. I did not expect the amount of feedback that I got. It
> is much appreciated.
>
> I spent most of my day profiling with VisualVM and it strengthened by
> beliefs that my problems do not appear to be related to anything but
> Wicket combined with our dated hardware. Please do not consider this a
> criticism. I understand that not a lot of people run servlet containers
> on this kind of hardware nowadays.
>
No criticism taken! The rest of your message does not show any evidence it
is actually a problem in Wicket!
I'd expect to see a call trace with the time of each method call that shows
where the most of the time is spent.
At the moment we have a guess that it is the markup loading, but we have no
idea whether it is the parsing (i.e. Wicket) or the file system read (i.e.
Java std APIs/slow disks), or something else.
>
> My database queries all run quickly and my domain classes are hardly
> even touched when the system starts. Our rather simple login page -
> which is stateless and does not query the database when the form is
> empty - takes 5-15 seconds to load on the first try. Subsequent requests
> take about 40-120ms (browser caching disabled). Once logged in, the
> other pages do not take as long, but they do feel sluggish until they
> have been requested once.
>
> I tried to only load the quickstart example as Martijn suggested. It
> starts more quickly than our own application but all things considered,
> its performance did not impress me and that application really is super
> simple. The first page load of the quickstart took about 2 seconds,
> after that it normalized to about 30ms per request.
>
> When all pages have been loaded once, things are absolutely fine. So I
> am considering Martin's approach of preloading components. That still
> leaves me with the considerable startup time but we will learn to live
> with that. Or we might switch from Tomcat to Jetty eventually.
>
> If anyone thinks I might be leaving some stuff on the table, I would be
> open to hire someone to do some consulting work on this. Please get in
> touch with me if you are interested.
>
> Cheers.
>
> Stan
>
>
> Martin Terra schreef op 2023-01-02 04:29:
>
> > Anything in wicket can be preloaded, but as premature optimization is
> > evil, you should profile your application.
> >
> > If you do not have debug access to a real/simulated environment then
> > the
> > least you can do is make your own thread logger to log what the threads
> > are
> > doing.
> >
> > **
> > Martin
> >
> > ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> > kirjoitti:
> >
> >> Hello
> >>
> >> Would you please describe your web application components? Database ?
> >> What services ran on the device?
> >>
> >> From: stan@stantastic.nl <st...@stantastic.nl>
> >> Date: Monday, January 2, 2023 at 5:23 AM
> >> To: users@wicket.apache.org <us...@wicket.apache.org>
> >> Subject: Wicket on low end hardware
> >>
> >> Hi,
> >>
> >> My use case for Wicket is a quite unconventional one. I use it as the
> >> framework for the web interface of an appliance that runs on low end
> >> hardware. The appliance doesn't have gigabytes of memory to waste or
> >> tens of CPU cores. It's more like Celeron powered hardware with maybe
> >> one or two gigabytes of RAM.
> >>
> >> I general this all works and customers are happy once the device is
> >> running. But I find that deployment is quite slow, and so are the
> >> first
> >> couple of page loads of the day. Just to be clear: I cannot really
> >> claim
> >> that my performance problems are all Wicket related. They may be, but
> >> they probably also are down to other underlying issues. A badly
> >> optimized database, or a badly configured servlet container come to
> >> mind...
> >>
> >> However, I was wondering if anyone has experience in using Wicket on
> >> low
> >> end hardware. I would be very interested in how to optimize for this.
> >>
> >> Thanks,
> >>
> >> Stan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket on low end hardware
Posted by st...@stantastic.nl.
Thanks everyone. I did not expect the amount of feedback that I got. It
is much appreciated.
I spent most of my day profiling with VisualVM and it strengthened by
beliefs that my problems do not appear to be related to anything but
Wicket combined with our dated hardware. Please do not consider this a
criticism. I understand that not a lot of people run servlet containers
on this kind of hardware nowadays.
My database queries all run quickly and my domain classes are hardly
even touched when the system starts. Our rather simple login page -
which is stateless and does not query the database when the form is
empty - takes 5-15 seconds to load on the first try. Subsequent requests
take about 40-120ms (browser caching disabled). Once logged in, the
other pages do not take as long, but they do feel sluggish until they
have been requested once.
I tried to only load the quickstart example as Martijn suggested. It
starts more quickly than our own application but all things considered,
its performance did not impress me and that application really is super
simple. The first page load of the quickstart took about 2 seconds,
after that it normalized to about 30ms per request.
When all pages have been loaded once, things are absolutely fine. So I
am considering Martin's approach of preloading components. That still
leaves me with the considerable startup time but we will learn to live
with that. Or we might switch from Tomcat to Jetty eventually.
If anyone thinks I might be leaving some stuff on the table, I would be
open to hire someone to do some consulting work on this. Please get in
touch with me if you are interested.
Cheers.
Stan
Martin Terra schreef op 2023-01-02 04:29:
> Anything in wicket can be preloaded, but as premature optimization is
> evil, you should profile your application.
>
> If you do not have debug access to a real/simulated environment then
> the
> least you can do is make your own thread logger to log what the threads
> are
> doing.
>
> **
> Martin
>
> ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com)
> kirjoitti:
>
>> Hello
>>
>> Would you please describe your web application components? Database ?
>> What services ran on the device?
>>
>> From: stan@stantastic.nl <st...@stantastic.nl>
>> Date: Monday, January 2, 2023 at 5:23 AM
>> To: users@wicket.apache.org <us...@wicket.apache.org>
>> Subject: Wicket on low end hardware
>>
>> Hi,
>>
>> My use case for Wicket is a quite unconventional one. I use it as the
>> framework for the web interface of an appliance that runs on low end
>> hardware. The appliance doesn't have gigabytes of memory to waste or
>> tens of CPU cores. It's more like Celeron powered hardware with maybe
>> one or two gigabytes of RAM.
>>
>> I general this all works and customers are happy once the device is
>> running. But I find that deployment is quite slow, and so are the
>> first
>> couple of page loads of the day. Just to be clear: I cannot really
>> claim
>> that my performance problems are all Wicket related. They may be, but
>> they probably also are down to other underlying issues. A badly
>> optimized database, or a badly configured servlet container come to
>> mind...
>>
>> However, I was wondering if anyone has experience in using Wicket on
>> low
>> end hardware. I would be very interested in how to optimize for this.
>>
>> Thanks,
>>
>> Stan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by Martin Terra <ma...@koodaripalvelut.com>.
Anything in wicket can be preloaded, but as premature optimization is
evil, you should profile your application.
If you do not have debug access to a real/simulated environment then the
least you can do is make your own thread logger to log what the threads are
doing.
**
Martin
ma 2. tammik. 2023 klo 3.19 Anna Eileen (shengchehsiao@gmail.com) kirjoitti:
> Hello
>
> Would you please describe your web application components? Database ?
> What services ran on the device?
>
>
> From: stan@stantastic.nl <st...@stantastic.nl>
> Date: Monday, January 2, 2023 at 5:23 AM
> To: users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Wicket on low end hardware
>
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the first
> couple of page loads of the day. Just to be clear: I cannot really claim
> that my performance problems are all Wicket related. They may be, but
> they probably also are down to other underlying issues. A badly
> optimized database, or a badly configured servlet container come to
> mind...
>
> However, I was wondering if anyone has experience in using Wicket on low
> end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
>
Re: Wicket on low end hardware
Posted by Maxim Solodovnik <so...@gmail.com>.
from mobile (sorry for typos ;)
On Tue, Jan 3, 2023, 00:26 <st...@stantastic.nl> wrote:
> It is not a very special setup.
>
> All devices run a Tomcat 9 servlet container. The servlet container runs
> a webservice that is being used onsite by other systems and an
> administration UI which is Wicket based. Both apps use the same H2
> database, which is tiny (<1MB) and only contains configuration and small
> amounts of temporary data. The data layer is based on MyBatis, and
> besides that there only are a couple of our own libraries there, and
> those really only contain some domain logic. The heavy lifting happens
> in the other app.
>
> Typical boot time for the servlet container is 10 to 20 seconds,
> depending on the hardware (it is about 4 seconds on my development
> machine).
Startup time can be decreased by using
-Djava.security.egd=file:/dev/./urandom
Which - isn't a lot if you ask me, but it annoys our support
> staff when they have to update the devices. And they probably do this a
> lot on a daily basis.
>
> When the first page of the day is requested it can take a good 5-15
> seconds for it to appear, even when the device has already been running
> for most of the day. On my development machine it is nearly instant.
>
> The Wicket application's performance does not improve when it is the
> only app being run on the device.
>
> But you and Martin are spot on. Instead of hoping for the golden lottery
> ticket, it is probably better for me to just spend half a day profiling
> and then ask a well researched question. So I guess I figured out what
> I'll be doing tomorrow morning ;-).
>
> Thanks!
>
> Stan
>
>
> Anna Eileen schreef op 2023-01-02 02:19:
>
> > Hello
> >
> > Would you please describe your web application components? Database ?
> > What services ran on the device?
> >
> > From: stan@stantastic.nl <st...@stantastic.nl>
> > Date: Monday, January 2, 2023 at 5:23 AM
> > To: users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Wicket on low end hardware
> >
> > Hi,
> >
> > My use case for Wicket is a quite unconventional one. I use it as the
> > framework for the web interface of an appliance that runs on low end
> > hardware. The appliance doesn't have gigabytes of memory to waste or
> > tens of CPU cores. It's more like Celeron powered hardware with maybe
> > one or two gigabytes of RAM.
> >
> > I general this all works and customers are happy once the device is
> > running. But I find that deployment is quite slow, and so are the first
> > couple of page loads of the day. Just to be clear: I cannot really
> > claim
> > that my performance problems are all Wicket related. They may be, but
> > they probably also are down to other underlying issues. A badly
> > optimized database, or a badly configured servlet container come to
> > mind...
> >
> > However, I was wondering if anyone has experience in using Wicket on
> > low
> > end hardware. I would be very interested in how to optimize for this.
> >
> > Thanks,
> >
> > Stan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket on low end hardware
Posted by "Locke, Jonathan (Luo Shibo)" <jo...@telenav.com>.
Jetty starts up quite a bit faster than Tomcat, so that’s an option too.
Jon
On Jan 2, 2023, at 12:51 PM, Martijn Dashorst <ma...@gmail.com> wrote:
As a simple test you could deploy a Wicket quick start to the device (make
sure it runs in deployment mode) to see if it still is slow. If that is the
case, you might need to look at the memory available for Tomcat. It might
need a bit more than it is configured with. Tweaking the memory settings
might also make a difference. If it is a low end device, it probably is
running the serialGC, you may need to switch to a different one like g1gc.
I've noticed that using "-XmxNg -XmsNg", where keeping N the same for
minimum and maximum shaves a lot of time from the GC, as it doesn't try to
minimize memory consumption.
Another thing you might look into is whether the application gets deployed
by Tomcat after the first request, or prior to that. (see Tomcat's
configuration for "deployOnStartup")
Martijn
On Mon, Jan 2, 2023 at 6:26 PM <st...@stantastic.nl>> wrote:
It is not a very special setup.
All devices run a Tomcat 9 servlet container. The servlet container runs
a webservice that is being used onsite by other systems and an
administration UI which is Wicket based. Both apps use the same H2
database, which is tiny (<1MB) and only contains configuration and small
amounts of temporary data. The data layer is based on MyBatis, and
besides that there only are a couple of our own libraries there, and
those really only contain some domain logic. The heavy lifting happens
in the other app.
Typical boot time for the servlet container is 10 to 20 seconds,
depending on the hardware (it is about 4 seconds on my development
machine). Which - isn't a lot if you ask me, but it annoys our support
staff when they have to update the devices. And they probably do this a
lot on a daily basis.
When the first page of the day is requested it can take a good 5-15
seconds for it to appear, even when the device has already been running
for most of the day. On my development machine it is nearly instant.
The Wicket application's performance does not improve when it is the
only app being run on the device.
But you and Martin are spot on. Instead of hoping for the golden lottery
ticket, it is probably better for me to just spend half a day profiling
and then ask a well researched question. So I guess I figured out what
I'll be doing tomorrow morning ;-).
Thanks!
Stan
Anna Eileen schreef op 2023-01-02 02:19:
Hello
Would you please describe your web application components? Database ?
What services ran on the device?
From: stan@stantastic.nl <st...@stantastic.nl>
Date: Monday, January 2, 2023 at 5:23 AM
To: users@wicket.apache.org <us...@wicket.apache.org>
Subject: Wicket on low end hardware
Hi,
My use case for Wicket is a quite unconventional one. I use it as the
framework for the web interface of an appliance that runs on low end
hardware. The appliance doesn't have gigabytes of memory to waste or
tens of CPU cores. It's more like Celeron powered hardware with maybe
one or two gigabytes of RAM.
I general this all works and customers are happy once the device is
running. But I find that deployment is quite slow, and so are the first
couple of page loads of the day. Just to be clear: I cannot really
claim
that my performance problems are all Wicket related. They may be, but
they probably also are down to other underlying issues. A badly
optimized database, or a badly configured servlet container come to
mind...
However, I was wondering if anyone has experience in using Wicket on
low
end hardware. I would be very interested in how to optimize for this.
Thanks,
Stan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
--
Become a Wicket expert, learn from the best: https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwicketinaction.com&c=E,1,f7QZv9TsdLd7FR2mmJNPb_CRjfQP1ZjeTQiPc-70BW1VzBB_LPj1UcHuDhbe__2o8suTqiYoi7ZQ_cVaxAe2V-fyJ-HrIyFB8XkvfWk1ECxj&typo=1
[EXTERNAL EMAIL] CAUTION: This email originated from outside of Telenav. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Re: Wicket on low end hardware
Posted by Martijn Dashorst <ma...@gmail.com>.
As a simple test you could deploy a Wicket quick start to the device (make
sure it runs in deployment mode) to see if it still is slow. If that is the
case, you might need to look at the memory available for Tomcat. It might
need a bit more than it is configured with. Tweaking the memory settings
might also make a difference. If it is a low end device, it probably is
running the serialGC, you may need to switch to a different one like g1gc.
I've noticed that using "-XmxNg -XmsNg", where keeping N the same for
minimum and maximum shaves a lot of time from the GC, as it doesn't try to
minimize memory consumption.
Another thing you might look into is whether the application gets deployed
by Tomcat after the first request, or prior to that. (see Tomcat's
configuration for "deployOnStartup")
Martijn
On Mon, Jan 2, 2023 at 6:26 PM <st...@stantastic.nl> wrote:
> It is not a very special setup.
>
> All devices run a Tomcat 9 servlet container. The servlet container runs
> a webservice that is being used onsite by other systems and an
> administration UI which is Wicket based. Both apps use the same H2
> database, which is tiny (<1MB) and only contains configuration and small
> amounts of temporary data. The data layer is based on MyBatis, and
> besides that there only are a couple of our own libraries there, and
> those really only contain some domain logic. The heavy lifting happens
> in the other app.
>
> Typical boot time for the servlet container is 10 to 20 seconds,
> depending on the hardware (it is about 4 seconds on my development
> machine). Which - isn't a lot if you ask me, but it annoys our support
> staff when they have to update the devices. And they probably do this a
> lot on a daily basis.
>
> When the first page of the day is requested it can take a good 5-15
> seconds for it to appear, even when the device has already been running
> for most of the day. On my development machine it is nearly instant.
>
> The Wicket application's performance does not improve when it is the
> only app being run on the device.
>
> But you and Martin are spot on. Instead of hoping for the golden lottery
> ticket, it is probably better for me to just spend half a day profiling
> and then ask a well researched question. So I guess I figured out what
> I'll be doing tomorrow morning ;-).
>
> Thanks!
>
> Stan
>
>
> Anna Eileen schreef op 2023-01-02 02:19:
>
> > Hello
> >
> > Would you please describe your web application components? Database ?
> > What services ran on the device?
> >
> > From: stan@stantastic.nl <st...@stantastic.nl>
> > Date: Monday, January 2, 2023 at 5:23 AM
> > To: users@wicket.apache.org <us...@wicket.apache.org>
> > Subject: Wicket on low end hardware
> >
> > Hi,
> >
> > My use case for Wicket is a quite unconventional one. I use it as the
> > framework for the web interface of an appliance that runs on low end
> > hardware. The appliance doesn't have gigabytes of memory to waste or
> > tens of CPU cores. It's more like Celeron powered hardware with maybe
> > one or two gigabytes of RAM.
> >
> > I general this all works and customers are happy once the device is
> > running. But I find that deployment is quite slow, and so are the first
> > couple of page loads of the day. Just to be clear: I cannot really
> > claim
> > that my performance problems are all Wicket related. They may be, but
> > they probably also are down to other underlying issues. A badly
> > optimized database, or a badly configured servlet container come to
> > mind...
> >
> > However, I was wondering if anyone has experience in using Wicket on
> > low
> > end hardware. I would be very interested in how to optimize for this.
> >
> > Thanks,
> >
> > Stan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Wicket on low end hardware
Posted by st...@stantastic.nl.
It is not a very special setup.
All devices run a Tomcat 9 servlet container. The servlet container runs
a webservice that is being used onsite by other systems and an
administration UI which is Wicket based. Both apps use the same H2
database, which is tiny (<1MB) and only contains configuration and small
amounts of temporary data. The data layer is based on MyBatis, and
besides that there only are a couple of our own libraries there, and
those really only contain some domain logic. The heavy lifting happens
in the other app.
Typical boot time for the servlet container is 10 to 20 seconds,
depending on the hardware (it is about 4 seconds on my development
machine). Which - isn't a lot if you ask me, but it annoys our support
staff when they have to update the devices. And they probably do this a
lot on a daily basis.
When the first page of the day is requested it can take a good 5-15
seconds for it to appear, even when the device has already been running
for most of the day. On my development machine it is nearly instant.
The Wicket application's performance does not improve when it is the
only app being run on the device.
But you and Martin are spot on. Instead of hoping for the golden lottery
ticket, it is probably better for me to just spend half a day profiling
and then ask a well researched question. So I guess I figured out what
I'll be doing tomorrow morning ;-).
Thanks!
Stan
Anna Eileen schreef op 2023-01-02 02:19:
> Hello
>
> Would you please describe your web application components? Database ?
> What services ran on the device?
>
> From: stan@stantastic.nl <st...@stantastic.nl>
> Date: Monday, January 2, 2023 at 5:23 AM
> To: users@wicket.apache.org <us...@wicket.apache.org>
> Subject: Wicket on low end hardware
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the first
> couple of page loads of the day. Just to be clear: I cannot really
> claim
> that my performance problems are all Wicket related. They may be, but
> they probably also are down to other underlying issues. A badly
> optimized database, or a badly configured servlet container come to
> mind...
>
> However, I was wondering if anyone has experience in using Wicket on
> low
> end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket on low end hardware
Posted by Anna Eileen <sh...@gmail.com>.
Hello
Would you please describe your web application components? Database ?
What services ran on the device?
From: stan@stantastic.nl <st...@stantastic.nl>
Date: Monday, January 2, 2023 at 5:23 AM
To: users@wicket.apache.org <us...@wicket.apache.org>
Subject: Wicket on low end hardware
Hi,
My use case for Wicket is a quite unconventional one. I use it as the
framework for the web interface of an appliance that runs on low end
hardware. The appliance doesn't have gigabytes of memory to waste or
tens of CPU cores. It's more like Celeron powered hardware with maybe
one or two gigabytes of RAM.
I general this all works and customers are happy once the device is
running. But I find that deployment is quite slow, and so are the first
couple of page loads of the day. Just to be clear: I cannot really claim
that my performance problems are all Wicket related. They may be, but
they probably also are down to other underlying issues. A badly
optimized database, or a badly configured servlet container come to
mind...
However, I was wondering if anyone has experience in using Wicket on low
end hardware. I would be very interested in how to optimize for this.
Thanks,
Stan
Re: Wicket on low end hardware
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Jan 3, 2023 at 10:12 AM Chris Colman
<ch...@stepaheadsoftware.com.invalid> wrote:
> We have lots of markup files (>1000) and have customized the markup and
> component resolution to support a kind of "markup driven" layout
> capability.
>
> There are times when the system will appear to hang but it's just that a
> form that has not been loaded since the last restart of the app is first
> loaded - it can take a good 10 seconds to show the form - but it always
> eventually shows so never actually "hung". When the form is opened again
> it opens instantly.
>
> It's not an ideal experience for end users.
>
> How many markup files does your app have?
>
> I often thought that it might be nice if there was a way to "pre-warm"
> the markup cache with every possible markup file during app start up so
> that no end user experiences this delay. If such a 'pre-warm' was
> available we would probably turn this on in production but not in dev.
>
I see no problem using ComponentRenderer to do this at App#init() time or
asynchronously if you want the app to be marked as "ready" by the servlet
container earlier.
>
> Regards,
> Chris
>
> On 2/01/2023 8:23 am, stan@stantastic.nl wrote:
> >
> >
> > Hi,
> >
> > My use case for Wicket is a quite unconventional one. I use it as the
> > framework for the web interface of an appliance that runs on low end
> > hardware. The appliance doesn't have gigabytes of memory to waste or
> > tens of CPU cores. It's more like Celeron powered hardware with maybe
> > one or two gigabytes of RAM.
> >
> > I general this all works and customers are happy once the device is
> > running. But I find that deployment is quite slow, and so are the
> > first couple of page loads of the day. Just to be clear: I cannot
> > really claim that my performance problems are all Wicket related. They
> > may be, but they probably also are down to other underlying issues. A
> > badly optimized database, or a badly configured servlet container come
> > to mind...
> >
> > However, I was wondering if anyone has experience in using Wicket on
> > low end hardware. I would be very interested in how to optimize for this.
> >
> > Thanks,
> >
> > Stan
> --
> Regards,
>
> Chris Colman
> *Feezily*,
> A product of /Step Ahead/ *Software* Pty Ltd
> Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
> Ph: 02 9656 1278
Re: Wicket on low end hardware
Posted by Chris Colman <ch...@stepaheadsoftware.com.INVALID>.
We have lots of markup files (>1000) and have customized the markup and
component resolution to support a kind of "markup driven" layout
capability.
There are times when the system will appear to hang but it's just that a
form that has not been loaded since the last restart of the app is first
loaded - it can take a good 10 seconds to show the form - but it always
eventually shows so never actually "hung". When the form is opened again
it opens instantly.
It's not an ideal experience for end users.
How many markup files does your app have?
I often thought that it might be nice if there was a way to "pre-warm"
the markup cache with every possible markup file during app start up so
that no end user experiences this delay. If such a 'pre-warm' was
available we would probably turn this on in production but not in dev.
Regards,
Chris
On 2/01/2023 8:23 am, stan@stantastic.nl wrote:
>
>
> Hi,
>
> My use case for Wicket is a quite unconventional one. I use it as the
> framework for the web interface of an appliance that runs on low end
> hardware. The appliance doesn't have gigabytes of memory to waste or
> tens of CPU cores. It's more like Celeron powered hardware with maybe
> one or two gigabytes of RAM.
>
> I general this all works and customers are happy once the device is
> running. But I find that deployment is quite slow, and so are the
> first couple of page loads of the day. Just to be clear: I cannot
> really claim that my performance problems are all Wicket related. They
> may be, but they probably also are down to other underlying issues. A
> badly optimized database, or a badly configured servlet container come
> to mind...
>
> However, I was wondering if anyone has experience in using Wicket on
> low end hardware. I would be very interested in how to optimize for this.
>
> Thanks,
>
> Stan
--
Regards,
Chris Colman
*Feezily*,
A product of /Step Ahead/ *Software* Pty Ltd
Web: feezily.com.au <http://feezily.com.au> Em: chrisc@stepahead.com.au
Ph: 02 9656 1278