In the preloading code please try with:
Application.get()
.getResourceSettings()
.getResourceStreamLocator()
.locate(clazz, path, style, variation, locale, (String) null, false)
where
clazz is AnyOfYourPagesAndMarkupContainersWithProperties.class
path is clazz.getName().replace('.', '/')
locale is NL
style is null
variation is null
does it help ?
On Fri, Jan 6, 2023 at 2:10 PM <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]>
> > 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
> > <[email protected]> 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<[email protected]> 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<[email protected]>
> > Date: Tuesday, January 3, 2023 at 11:37 PM
> > To:[email protected] <[email protected]>
> > Cc:[email protected] <[email protected]>
> > 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 [email protected] 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 ([email protected])
> > kirjoitti:
> >
> > Hello
> >
> > Would you please describe your web application components? Database ?
> > What services ran on the device?
> >
> > From:[email protected] <[email protected]>
> > Date: Monday, January 2, 2023 at 5:23 AM
> > To:[email protected] <[email protected]>
> > 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:[email protected]
> > For additional commands, e-mail:[email protected]
> --
> Regards,
>
> Chris Colman
> *Feezily*,
> A product of /Step Ahead/ *Software* Pty Ltd
> Web: feezily.com.au <http://feezily.com.au> Em: [email protected]
> Ph: 02 9656 1278
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
