You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Stephen Cameron <st...@gmail.com> on 2015/09/28 14:51:33 UTC
moving to test & production, how to optimise speed of response?
Hi,
I am installing on a test server tomorrow, what can I set to optimise speed
of response? I was looking that the security module video online and
thinking: gee that is fast! It would be good to get mine that nippy :)
I know that there are cache optimisations for Wicket and I see a warning
that I am working in DEVELOPMENT mode when Jetty starts.
Just wondering if there is a list anywhere of things to do in the
switch-over?
Cheers
Steve C
Re: moving to test & production, how to optimise speed of response?
Posted by Stephen Cameron <st...@gmail.com>.
No measurement, just an observation. the reponse from the restful viewer
seems to me to be almost instantaneous, whereas the wicket viewer a few
seconds at least.
I am also comparing current Isis wicket performance against what I observe
in the security module video that Dan did, I'd say my speed is about half
what I see there.
Also, its slower than the system I am replacing, I cannot see that
difference being due to machine specs. That system is PHP, so template
based, its crap in other respects, but very fast. A OO server-side
component based system, I imagine, is always going to be bit slower due to
AJAX requests.
On Tue, Sep 29, 2015 at 8:42 PM, Jeroen van der Wal <je...@stromboli.it>
wrote:
> I've never seen the restful viewer outperform the wicket viewer. How did
> you measure?
>
> On 29 September 2015 at 12:25, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > On Tue, Sep 29, 2015 at 12:22 PM, Stephen Cameron <
> > steve.cameron.62@gmail.com> wrote:
> >
> > > I don't think its anything to do with database access, I am starting
> with
> > > an empty in-memory database. This will be an interesting challenge to
> try
> > > and track down the issue. I am struck by the big difference in
> > > responsiveness of the restful-objects viewer vs the wicket viewer, with
> > no
> > > criticism of wicket intended, all indications are that its performance
> is
> > > very good when benchmarked.
> > >
> >
> > Wicket is never the problem ;-)
> >
> > It should be easy for you to profile your app with jProfiler/YourKit.
> >
> >
> > >
> > > On Tue, Sep 29, 2015 at 2:06 AM, Dan Haywood <
> > dan@haywood-associates.co.uk
> > > >
> > > wrote:
> > >
> > > > There isn't really any list, no.
> > > >
> > > > Actually, on my todo list is to do some performance tuning; things
> have
> > > > certainly slowed down over the last few releases. I have one or two
> > > > theories as to why, but haven't researched them as of yet.
> > > >
> > > > You might want to look configure logging to view all SQL queries and
> to
> > > > search for any occurrences of the N+1 problem; eg configure
> > > >
> > > > log4j.appender.sql=org.apache.log4j.RollingFileAppender
> > > > log4j.appender.sql.File=./logs/sql.log
> > > > log4j.appender.sql.Append=false
> > > > log4j.appender.sql.layout=org.apache.log4j.PatternLayout
> > > > log4j.appender.sql.layout.ConversionPattern=%d{yyyy-MM-dd
> HH:mm:ss.SSS}
> > > > %m%n
> > > >
> > > > and
> > > >
> > > > log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console, sql
> > > > log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console, sql
> > > >
> > > > in logging.properties and then monitor sql.log. I use baretail (on
> > > > windows) which supports highlighting of lines; makes it easy to see
> > which
> > > > tables are being hit repeatedly.
> > > >
> > > >
> > > > Another thing you could explore is to use selective caching, eg using
> > the
> > > > QueryResultsCache [1]
> > > >
> > > > HTH (a bit)
> > > > Dan
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://isis.apache.org/guides/rg.html#_rg_services-api_manpage-QueryResultsCache
> > > >
> > > >
> > > >
> > > >
> > > > On 28 September 2015 at 13:51, Stephen Cameron <
> > > steve.cameron.62@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am installing on a test server tomorrow, what can I set to
> optimise
> > > > speed
> > > > > of response? I was looking that the security module video online
> and
> > > > > thinking: gee that is fast! It would be good to get mine that nippy
> > :)
> > > > >
> > > > > I know that there are cache optimisations for Wicket and I see a
> > > warning
> > > > > that I am working in DEVELOPMENT mode when Jetty starts.
> > > > >
> > > > > Just wondering if there is a list anywhere of things to do in the
> > > > > switch-over?
> > > > >
> > > > > Cheers
> > > > > Steve C
> > > > >
> > > >
> > >
> >
>
Re: moving to test & production, how to optimise speed of response?
Posted by Jeroen van der Wal <je...@stromboli.it>.
I've never seen the restful viewer outperform the wicket viewer. How did
you measure?
On 29 September 2015 at 12:25, Martin Grigorov <mg...@apache.org> wrote:
> On Tue, Sep 29, 2015 at 12:22 PM, Stephen Cameron <
> steve.cameron.62@gmail.com> wrote:
>
> > I don't think its anything to do with database access, I am starting with
> > an empty in-memory database. This will be an interesting challenge to try
> > and track down the issue. I am struck by the big difference in
> > responsiveness of the restful-objects viewer vs the wicket viewer, with
> no
> > criticism of wicket intended, all indications are that its performance is
> > very good when benchmarked.
> >
>
> Wicket is never the problem ;-)
>
> It should be easy for you to profile your app with jProfiler/YourKit.
>
>
> >
> > On Tue, Sep 29, 2015 at 2:06 AM, Dan Haywood <
> dan@haywood-associates.co.uk
> > >
> > wrote:
> >
> > > There isn't really any list, no.
> > >
> > > Actually, on my todo list is to do some performance tuning; things have
> > > certainly slowed down over the last few releases. I have one or two
> > > theories as to why, but haven't researched them as of yet.
> > >
> > > You might want to look configure logging to view all SQL queries and to
> > > search for any occurrences of the N+1 problem; eg configure
> > >
> > > log4j.appender.sql=org.apache.log4j.RollingFileAppender
> > > log4j.appender.sql.File=./logs/sql.log
> > > log4j.appender.sql.Append=false
> > > log4j.appender.sql.layout=org.apache.log4j.PatternLayout
> > > log4j.appender.sql.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
> > > %m%n
> > >
> > > and
> > >
> > > log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console, sql
> > > log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console, sql
> > >
> > > in logging.properties and then monitor sql.log. I use baretail (on
> > > windows) which supports highlighting of lines; makes it easy to see
> which
> > > tables are being hit repeatedly.
> > >
> > >
> > > Another thing you could explore is to use selective caching, eg using
> the
> > > QueryResultsCache [1]
> > >
> > > HTH (a bit)
> > > Dan
> > >
> > > [1]
> > >
> > >
> >
> http://isis.apache.org/guides/rg.html#_rg_services-api_manpage-QueryResultsCache
> > >
> > >
> > >
> > >
> > > On 28 September 2015 at 13:51, Stephen Cameron <
> > steve.cameron.62@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I am installing on a test server tomorrow, what can I set to optimise
> > > speed
> > > > of response? I was looking that the security module video online and
> > > > thinking: gee that is fast! It would be good to get mine that nippy
> :)
> > > >
> > > > I know that there are cache optimisations for Wicket and I see a
> > warning
> > > > that I am working in DEVELOPMENT mode when Jetty starts.
> > > >
> > > > Just wondering if there is a list anywhere of things to do in the
> > > > switch-over?
> > > >
> > > > Cheers
> > > > Steve C
> > > >
> > >
> >
>
Re: moving to test & production, how to optimise speed of response?
Posted by Stephen Cameron <st...@gmail.com>.
Thanks Martin I will give that a go over the next few days, just comparing
the responsiveness of my app running on a local machine with the wicket
demos here http://www.wicket-library.com, there is a noticeable difference.
On Tue, Sep 29, 2015 at 8:25 PM, Martin Grigorov <mg...@apache.org>
wrote:
> On Tue, Sep 29, 2015 at 12:22 PM, Stephen Cameron <
> steve.cameron.62@gmail.com> wrote:
>
> > I don't think its anything to do with database access, I am starting with
> > an empty in-memory database. This will be an interesting challenge to try
> > and track down the issue. I am struck by the big difference in
> > responsiveness of the restful-objects viewer vs the wicket viewer, with
> no
> > criticism of wicket intended, all indications are that its performance is
> > very good when benchmarked.
> >
>
> Wicket is never the problem ;-)
>
> It should be easy for you to profile your app with jProfiler/YourKit.
>
>
> >
> > On Tue, Sep 29, 2015 at 2:06 AM, Dan Haywood <
> dan@haywood-associates.co.uk
> > >
> > wrote:
> >
> > > There isn't really any list, no.
> > >
> > > Actually, on my todo list is to do some performance tuning; things have
> > > certainly slowed down over the last few releases. I have one or two
> > > theories as to why, but haven't researched them as of yet.
> > >
> > > You might want to look configure logging to view all SQL queries and to
> > > search for any occurrences of the N+1 problem; eg configure
> > >
> > > log4j.appender.sql=org.apache.log4j.RollingFileAppender
> > > log4j.appender.sql.File=./logs/sql.log
> > > log4j.appender.sql.Append=false
> > > log4j.appender.sql.layout=org.apache.log4j.PatternLayout
> > > log4j.appender.sql.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
> > > %m%n
> > >
> > > and
> > >
> > > log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console, sql
> > > log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console, sql
> > >
> > > in logging.properties and then monitor sql.log. I use baretail (on
> > > windows) which supports highlighting of lines; makes it easy to see
> which
> > > tables are being hit repeatedly.
> > >
> > >
> > > Another thing you could explore is to use selective caching, eg using
> the
> > > QueryResultsCache [1]
> > >
> > > HTH (a bit)
> > > Dan
> > >
> > > [1]
> > >
> > >
> >
> http://isis.apache.org/guides/rg.html#_rg_services-api_manpage-QueryResultsCache
> > >
> > >
> > >
> > >
> > > On 28 September 2015 at 13:51, Stephen Cameron <
> > steve.cameron.62@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I am installing on a test server tomorrow, what can I set to optimise
> > > speed
> > > > of response? I was looking that the security module video online and
> > > > thinking: gee that is fast! It would be good to get mine that nippy
> :)
> > > >
> > > > I know that there are cache optimisations for Wicket and I see a
> > warning
> > > > that I am working in DEVELOPMENT mode when Jetty starts.
> > > >
> > > > Just wondering if there is a list anywhere of things to do in the
> > > > switch-over?
> > > >
> > > > Cheers
> > > > Steve C
> > > >
> > >
> >
>
Re: moving to test & production, how to optimise speed of response?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Sep 29, 2015 at 12:22 PM, Stephen Cameron <
steve.cameron.62@gmail.com> wrote:
> I don't think its anything to do with database access, I am starting with
> an empty in-memory database. This will be an interesting challenge to try
> and track down the issue. I am struck by the big difference in
> responsiveness of the restful-objects viewer vs the wicket viewer, with no
> criticism of wicket intended, all indications are that its performance is
> very good when benchmarked.
>
Wicket is never the problem ;-)
It should be easy for you to profile your app with jProfiler/YourKit.
>
> On Tue, Sep 29, 2015 at 2:06 AM, Dan Haywood <dan@haywood-associates.co.uk
> >
> wrote:
>
> > There isn't really any list, no.
> >
> > Actually, on my todo list is to do some performance tuning; things have
> > certainly slowed down over the last few releases. I have one or two
> > theories as to why, but haven't researched them as of yet.
> >
> > You might want to look configure logging to view all SQL queries and to
> > search for any occurrences of the N+1 problem; eg configure
> >
> > log4j.appender.sql=org.apache.log4j.RollingFileAppender
> > log4j.appender.sql.File=./logs/sql.log
> > log4j.appender.sql.Append=false
> > log4j.appender.sql.layout=org.apache.log4j.PatternLayout
> > log4j.appender.sql.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
> > %m%n
> >
> > and
> >
> > log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console, sql
> > log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console, sql
> >
> > in logging.properties and then monitor sql.log. I use baretail (on
> > windows) which supports highlighting of lines; makes it easy to see which
> > tables are being hit repeatedly.
> >
> >
> > Another thing you could explore is to use selective caching, eg using the
> > QueryResultsCache [1]
> >
> > HTH (a bit)
> > Dan
> >
> > [1]
> >
> >
> http://isis.apache.org/guides/rg.html#_rg_services-api_manpage-QueryResultsCache
> >
> >
> >
> >
> > On 28 September 2015 at 13:51, Stephen Cameron <
> steve.cameron.62@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > I am installing on a test server tomorrow, what can I set to optimise
> > speed
> > > of response? I was looking that the security module video online and
> > > thinking: gee that is fast! It would be good to get mine that nippy :)
> > >
> > > I know that there are cache optimisations for Wicket and I see a
> warning
> > > that I am working in DEVELOPMENT mode when Jetty starts.
> > >
> > > Just wondering if there is a list anywhere of things to do in the
> > > switch-over?
> > >
> > > Cheers
> > > Steve C
> > >
> >
>
Re: moving to test & production, how to optimise speed of response?
Posted by Stephen Cameron <st...@gmail.com>.
I don't think its anything to do with database access, I am starting with
an empty in-memory database. This will be an interesting challenge to try
and track down the issue. I am struck by the big difference in
responsiveness of the restful-objects viewer vs the wicket viewer, with no
criticism of wicket intended, all indications are that its performance is
very good when benchmarked.
On Tue, Sep 29, 2015 at 2:06 AM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> There isn't really any list, no.
>
> Actually, on my todo list is to do some performance tuning; things have
> certainly slowed down over the last few releases. I have one or two
> theories as to why, but haven't researched them as of yet.
>
> You might want to look configure logging to view all SQL queries and to
> search for any occurrences of the N+1 problem; eg configure
>
> log4j.appender.sql=org.apache.log4j.RollingFileAppender
> log4j.appender.sql.File=./logs/sql.log
> log4j.appender.sql.Append=false
> log4j.appender.sql.layout=org.apache.log4j.PatternLayout
> log4j.appender.sql.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
> %m%n
>
> and
>
> log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console, sql
> log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console, sql
>
> in logging.properties and then monitor sql.log. I use baretail (on
> windows) which supports highlighting of lines; makes it easy to see which
> tables are being hit repeatedly.
>
>
> Another thing you could explore is to use selective caching, eg using the
> QueryResultsCache [1]
>
> HTH (a bit)
> Dan
>
> [1]
>
> http://isis.apache.org/guides/rg.html#_rg_services-api_manpage-QueryResultsCache
>
>
>
>
> On 28 September 2015 at 13:51, Stephen Cameron <steve.cameron.62@gmail.com
> >
> wrote:
>
> > Hi,
> >
> > I am installing on a test server tomorrow, what can I set to optimise
> speed
> > of response? I was looking that the security module video online and
> > thinking: gee that is fast! It would be good to get mine that nippy :)
> >
> > I know that there are cache optimisations for Wicket and I see a warning
> > that I am working in DEVELOPMENT mode when Jetty starts.
> >
> > Just wondering if there is a list anywhere of things to do in the
> > switch-over?
> >
> > Cheers
> > Steve C
> >
>
Re: moving to test & production, how to optimise speed of response?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
There isn't really any list, no.
Actually, on my todo list is to do some performance tuning; things have
certainly slowed down over the last few releases. I have one or two
theories as to why, but haven't researched them as of yet.
You might want to look configure logging to view all SQL queries and to
search for any occurrences of the N+1 problem; eg configure
log4j.appender.sql=org.apache.log4j.RollingFileAppender
log4j.appender.sql.File=./logs/sql.log
log4j.appender.sql.Append=false
log4j.appender.sql.layout=org.apache.log4j.PatternLayout
log4j.appender.sql.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS} %m%n
and
log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console, sql
log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console, sql
in logging.properties and then monitor sql.log. I use baretail (on
windows) which supports highlighting of lines; makes it easy to see which
tables are being hit repeatedly.
Another thing you could explore is to use selective caching, eg using the
QueryResultsCache [1]
HTH (a bit)
Dan
[1]
http://isis.apache.org/guides/rg.html#_rg_services-api_manpage-QueryResultsCache
On 28 September 2015 at 13:51, Stephen Cameron <st...@gmail.com>
wrote:
> Hi,
>
> I am installing on a test server tomorrow, what can I set to optimise speed
> of response? I was looking that the security module video online and
> thinking: gee that is fast! It would be good to get mine that nippy :)
>
> I know that there are cache optimisations for Wicket and I see a warning
> that I am working in DEVELOPMENT mode when Jetty starts.
>
> Just wondering if there is a list anywhere of things to do in the
> switch-over?
>
> Cheers
> Steve C
>