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 <martijn.dasho...@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 <s...@stantastic.nl<mailto: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: 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.
