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 <s...@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: 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
