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