Re: Wicket on low end hardware

[Martin Grigorov]

On Tue, Jan 3, 2023 at 4:58 PM  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 (shengchehs...@gmail.com)
> > kirjoitti:
> >
> >> Hello
> >>
> >> Would you please describe your web application components? Database ?
> >> What services ran on the device?
> >>
> >> From: s...@stantastic.nl 
> >> Date: Monday, January 2, 2023 at 5:23 AM
> >> To: users@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-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Wicket on low end hardware

[Locke, Jonathan (Luo Shibo)]

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


[social-Java-On-Baeldung-2.jpg]
Tiered Compilation in JVM
baeldung.com



On Jan 3, 2023, at 6:48 PM, Martin Terra  
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 (shengchehs...@gmail.com)
kirjoitti:

Dear Martin

I don’t know how to do “pre-touch”, do you have any example?

From: Martin Terra 
Date: Tuesday, January 3, 2023 at 11:37 PM
To: s...@stantastic.nl 
Cc: users@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 s...@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 (shengchehs...@gmail.com)
kirjoitti:

Hello

Would you please describe your web application components? Database ?
What services ran on the device?

From: s...@stantastic.nl 
Date: Monday, January 2, 2023 at 5:23 AM
To: users@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

[Martin Terra]

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 (shengchehs...@gmail.com)
kirjoitti:

> Dear Martin
>
> I don’t know how to do “pre-touch”, do you have any example?
>
> From: Martin Terra 
> Date: Tuesday, January 3, 2023 at 11:37 PM
> To: s...@stantastic.nl 
> Cc: users@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 s...@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 (shengchehs...@gmail.com)
> > > kirjoitti:
> > >
> > >> Hello
> > >>
> > >> Would you please describe your web application components? Database ?
> > >> What services ran on the device?
> > >>
> > >> From: s...@stantastic.nl 
> > >> Date: Monday, January 2, 2023 at 5:23 AM
> > >> To: users@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

[Anna Eileen Eileen]

Dear Martin

I don’t know how to do “pre-touch”, do you have any example?

From: Martin Terra 
Date: Tuesday, January 3, 2023 at 11:37 PM
To: s...@stantastic.nl 
Cc: users@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 s...@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 (shengchehs...@gmail.com)
> > kirjoitti:
> >
> >> Hello
> >>
> >> Would you please describe your web application components? Database ?
> >> What services ran on the device?
> >>
> >> From: s...@stantastic.nl 
> >> Date: Monday, January 2, 2023 at 5:23 AM
> >> To: users@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

[François Meillet]

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  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 s...@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 (shengchehs...@gmail.com)
>>> kirjoitti:
>>> 
 Hello
 
 Would you please describe your web application components? Database ?
 What services ran on the device?
 
 From: s...@stantastic.nl 
 Date: Monday, January 2, 2023 at 5:23 AM
 To: users@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket on low end hardware

[Martin Terra]

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 s...@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 (shengchehs...@gmail.com)
> > kirjoitti:
> >
> >> Hello
> >>
> >> Would you please describe your web application components? Database ?
> >> What services ran on the device?
> >>
> >> From: s...@stantastic.nl 
> >> Date: Monday, January 2, 2023 at 5:23 AM
> >> To: users@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

[stan]

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 (shengchehs...@gmail.com) 
kirjoitti:



Hello

Would you please describe your web application components? Database ?
What services ran on the device?

From: s...@stantastic.nl 
Date: Monday, January 2, 2023 at 5:23 AM
To: users@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket on low end hardware

[Martin Grigorov]

On Tue, Jan 3, 2023 at 10:12 AM Chris Colman
 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, s...@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  Em: chr...@stepahead.com.au
> Ph: 02 9656 1278

Re: wicket-bean-validation 10.0.0-M1-SNAPSHOT not available?

[Francesco Chicchiriccò]

Thank you Martin, the situation is indeed fine.
Actually, I was trying to find the artifacts via the web UI of 
https://repository.apache.org but couldn't make it.

I was also under the wrong assumption that the Apache SNAPSHOT repo was already 
defined in the project: your answer forced me to carry on the appropriate 
checks and fix.

Regards.

On 2023/01/03 08:39:36 Martin Grigorov wrote:
> https://repository.apache.org/service/local/repo_groups/snapshots-group/content/org/apache/wicket/wicket-devutils/10.0.0-M1-SNAPSHOT/wicket-devutils-10.0.0-M1-20221118.110647-169.pom
> https://repository.apache.org/service/local/repo_groups/snapshots-group/content/org/apache/wicket/wicket-bean-validation/10.0.0-M1-SNAPSHOT/wicket-bean-validation-10.0.0-M1-20221118.110647-167.pom
> 
> Both seem to be there.
> 
> 
> On Tue, Jan 3, 2023 at 9:35 AM Francesco Chicchiriccò 
> wrote:
> 
> > Forgot to add that the same happens with wicket-devutils.
> >
> > Regards.
> >
> > On 2023/01/03 07:33:36 Francesco Chicchiriccò wrote:
> > > Hi there,
> > > I am working to upgrade our Wicket apps to Spring Boot 3 and found that
> > 10.0.0-M1-SNAPSHOT plays nicely with it.
> > >
> > > It seems however, that
> > >
> > > org.apache.wicket:wicket-bean-validation:10.0.0-M1-SNAPSHOT
> > >
> > > is not available from
> > >
> > > https://repository.apache.org/
> > >
> > > while the module seems to be regularly present in the source tree at
> > >
> > > https://github.com/apache/wicket/tree/master/wicket-bean-validation
> > >
> > > Maybe something bad with CI deployment?
> > >
> > > Regards.
> > >
> > > --
> > > Francesco Chicchiriccò
> > >
> > > Tirasa - Open Source Excellence
> > > http://www.tirasa.net/
> > >
> > > Member at The Apache Software Foundation
> > > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> > > http://home.apache.org/~ilgrosso/
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: wicket-bean-validation 10.0.0-M1-SNAPSHOT not available?

[Martin Grigorov]

https://repository.apache.org/service/local/repo_groups/snapshots-group/content/org/apache/wicket/wicket-devutils/10.0.0-M1-SNAPSHOT/wicket-devutils-10.0.0-M1-20221118.110647-169.pom
https://repository.apache.org/service/local/repo_groups/snapshots-group/content/org/apache/wicket/wicket-bean-validation/10.0.0-M1-SNAPSHOT/wicket-bean-validation-10.0.0-M1-20221118.110647-167.pom

Both seem to be there.


On Tue, Jan 3, 2023 at 9:35 AM Francesco Chicchiriccò 
wrote:

> Forgot to add that the same happens with wicket-devutils.
>
> Regards.
>
> On 2023/01/03 07:33:36 Francesco Chicchiriccò wrote:
> > Hi there,
> > I am working to upgrade our Wicket apps to Spring Boot 3 and found that
> 10.0.0-M1-SNAPSHOT plays nicely with it.
> >
> > It seems however, that
> >
> > org.apache.wicket:wicket-bean-validation:10.0.0-M1-SNAPSHOT
> >
> > is not available from
> >
> > https://repository.apache.org/
> >
> > while the module seems to be regularly present in the source tree at
> >
> > https://github.com/apache/wicket/tree/master/wicket-bean-validation
> >
> > Maybe something bad with CI deployment?
> >
> > Regards.
> >
> > --
> > Francesco Chicchiriccò
> >
> > Tirasa - Open Source Excellence
> > http://www.tirasa.net/
> >
> > Member at The Apache Software Foundation
> > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> > http://home.apache.org/~ilgrosso/
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Wicket on low end hardware

[Chris Colman]

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, s...@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  Em: chr...@stepahead.com.au 
Ph: 02 9656 1278