Hi Martin,
My system locale is nl.
The application's default language is English. But all properties files
have '_nl' counterparts, so the application runs in Dutch as well as it
does in English. Most users use the Dutch locale.
Every WebPage has an English (default) properties file, and a Dutch one.
There also is a MyApplication.properties and a
MyApplication_nl.properties. I also add an extra resource bundle that I
use to rebrand the application for a subcontractor if that is necessary.
That one is being added in the app.init() code using:
getResourceSettings().getStringResourceLoaders().add(new
BundleStringResourceLoader("RebrandSubcontractorName"));
A quick count tells me that my application has about 85 *.properties
files.
Stan
Martin Grigorov schreef op 2023-01-06 12:59:
On Fri, Jan 6, 2023 at 11:44 AM <s...@stantastic.nl> wrote:
Hi all,
As I was implementing markup caching by adding it directly to the
MarkupCache, I found my gains weren't as big as I had expected (I
guess
premature optimization really is the root of all evil...). My tests
using ComponentRenderer were much more promising.
So I started to dig into this deeper and found that the first call to
Localizer->getString() on our hardware takes between 1500 and 2000ms.
I
then started to investigate if this can also be preloaded but I am
having a hard time coming up with something effective.
Does anyone have experience with this?
What is the system locale ?
And what resource bunldes does your application use ? E.g.
MyApplication_nl.properties and MyApplication.properties
Thanks.
Stan
Martin Grigorov schreef op 2023-01-06 09:52:
Hi,
Here is the minimum for preloading the markup of any MarkupContainer:
MarkupFactory markupFactory =
Application.get().getMarkupSettings().getMarkupFactory();
markupFactory.getMarkup(new AnyMarkupContainer(), false);
AnyMarkupContainer could be a Page, Panel, Border, ..., any
MarkupContainer
impl.
The Markup will be stored in the MarkupCache for the following needs.
On Fri, Jan 6, 2023 at 5:56 AM Maxim Solodovnik <solomax...@gmail.com>
wrote:
You can render components, not just pages
According to the list
You can create the list of all HTML files, find correspondent Java
files
and try to render them
from mobile (sorry for typos ;)
On Fri, Jan 6, 2023, 01:20 Chris Colman
<chr...@stepaheadsoftware.com.invalid> wrote:
In my case I have lots of modal forms (using Wicketstuff ModalX) that
can be potentially opened by the user.
Doing a 'pre-fetch' of each page won't 'pre-warm' the markup cache for
all of those modal forms as the page markup has no reference to the
modal form contents/markup as it is using ModalX's generic modal dialog
feature so there's no need to specify which form you wish to open in
the
markup of the page that will open it.
I wonder if it would be possible to develop a 'parse all markup' that
would pick up the markup for these forms as well, not just for the
pages.
On 5/01/2023 12:31 am, Martin Grigorov wrote: On Wed, Jan 4, 2023 at
2:48 PM<s...@stantastic.nl> wrote:
Hi Anna,
I attempted this, and ended up with a method like this:
private void preloadPages(Collection<Class<? extends
IRequestablePage>>
pages) {
final Supplier<ISessionStore> oldSessionStoreProvider =
getSessionStoreProvider();
try {
setSessionStoreProvider(() -> new MockSessionStore());
final RequestCycle rc = createRequestCycle(new MockWebRequest(new
Url()), new MockWebResponse());
ThreadContext.setRequestCycle(rc);
for (Class<? extends IRequestablePage> p : pages)
ComponentRenderer.renderPage(new PageProvider(p));
}
finally {
setSessionStoreProvider(oldSessionStoreProvider);
}
}
Which I have not been able to test on more than one page yet, because
I
still need to implement something to render my other pages with an
AuthenticatedWebSession. My login page's first load time has been
reduced to about 10% of what it was though.
I call that method from app.init().
I have some doubts over Martin's claim that it is possible to do this
on
a different thread. As you may notice, I had to change the
SessionStoreProvider to make this work. If I am correct that means
that
as long as this method runs, all sessions will be handled by the
MockSessionStore.
Stan
Anna Eileen Eileen schreef op 2023-01-04 01:22:
Dear Martin
I don't know how to do "pre-touch", do you have any example?
From: Martin Terra<martin.te...@koodaripalvelut.com>
Date: Tuesday, January 3, 2023 at 11:37 PM
To:s...@stantastic.nl <s...@stantastic.nl>
Cc:users@wicket.apache.org <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.58s...@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. You
may want to check the implementation of Wicket Native WebSocket
module
[1]
WebSocket messages come in a TCP connection, i.e. there is no HTTP
session/request/response.
Because of that Wicket Native WebSocket stores the app name, session
id,
page id / resource name at the handshake time and later fetches /
re-creates those to process any websocket message.
I agree that the setup is not something simple. Loading a page may
depend
on external resources (like a user in your case, or an open DB
connection,
...).
Maybe you can simplify the preloading to just populate the Markup
cache
instead of fully render all pages.
IMO this deserves to be added to Wicket APIs as a helper or something!
1.
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L234
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
---------------------------------------------------------------------
To unsubscribe, e-mail:users-unsubscr...@wicket.apache.org
For additional commands, e-mail:users-h...@wicket.apache.org
--
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
---------------------------------------------------------------------
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
