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
>
>
