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
>
