Re: Slowdown with roundup 2.3.0 vs roundup 2.1.0?
Ralf Schlatterbeck <[email protected]> Fri, 27 Oct 2023 11:54:49 +0200
| Newsgroups | gmane.comp.bug-tracking.roundup.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Oct 26, 2023 at 08:24:41PM -0400, John P. Rouillard wrote:
> Hi all:
>
> In private email Norbert Schlemmer and I have been debugging an issue
> where his 2.1.0 docker installation runs much faster than his 2.3.0
> docker install.
>
> Both of them are deployed using roundup-server. He is seeing a 1.7 or
> so second delay in the REST interface under 2.3.0 that is not present
> under 2.1.0.
First of all: I'm not seeing this in my test instance with
roundup-server (latest dev branch). The login template uses 0.08s
according to in-browser cold cache analysis (inspector, 'Network' tab).
A normal template takes .58s.
Maybe this is a similar issue we had with the CGI script: Not chaching
the tracker instance? For CGI (see RequestDispatcher in
roundup.cgi.wsgi_handler) we introduced a feature flag 'cache_tracker'
that turns on caching of the tracker instance, not reopening the
database and compiling the templates (and the i18n stuff!) for every
request.
The roundup server script in roundup/scripts/roundup_server.py *does*
use chaching of the tracker instance by default, though.
In inner_run_cgi we have:
# do the roundup thing
tracker = self.get_tracker(tracker_name)
tracker.Client(tracker, self, env).main()
In get_trackers there is support for caching trackers in
self.TRACKERS but the default is that no chaching occurs when
self.TRACKERS evaluates to false, the default is that it is initialized
with None. In function 'get_server' self.TRACKERS is conditionally
cached if debug is turned off. Debug is set via the multiprocess option
of the server config.
So by default we *do* tracker caching unless debug is set.
So maybe you are using a server configuration file with debug set or
using an explicit --multiprocess=debug option?
> The @stats=true query param provides stats that look pretty much the
> same for both 2.1.0 and 2.3.0 (sub .05s elapsed time) . However the
> times produced by @stats seems to be much less than the times measured
> say using curl (1.5s or so).
That would point in the same direction because the stats start when there
is a tracker instance.
Kind regards,
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: [email protected]