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