Discussion:
bugzilla page loading very slow
Philip Parsons (Velindre - Medical Physics)
2018-06-26 13:53:41 UTC
Permalink
Hi,

I've had to perform a restore of Bugzilla and since doing so I'm finding that it's takes 5 to 10 seconds to open a page (this is true of the top links - Home, Browse etc, and any saved searches at the bottom too). After a click nothing happens for that time and then the page displays very quickly. It previously was much quicker than this. Our installation isn't particularly large.

I've run runtests.pl (see below). Can anyone help as to what could be the issues?

Thanks in advance for your advice.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

$ /c/Perl64/bin/perl5.24.1.exe runtests.pl
#
# It looks like you don't have a C compiler and make utility installed. Trying
# to install dmake and the MinGW gcc compiler using the Perl Package Manager.
# This may take a a few minutes...
#
# ppm.bat install failed: 500 Can't connect to ppm4.activestate.com:80
#
# It looks like the installation of dmake and MinGW has failed. You will not
# be able to run Makefile commands or compile C extension code. Please check
# your internet connection and your proxy settings!
#
ppm.bat install failed: 500 Can't connect to ppm4.activestate.com:80
Use of uninitialized value in pattern match (m//) at C:\Perl64\lib/ExtUtils/MM_Win32.pm line 40 , <DATA> line 755.
Use of uninitialized value in pattern match (m//) at C:\Perl64\lib/ExtUtils/MM_Win32.pm line 41 , <DATA> line 755.
Use of uninitialized value in pattern match (m//) at C:\Perl64\lib/ExtUtils/MM_Win32.pm line 42 , <DATA> line 755.
# Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m /\${ <-- HERE [^}]+}/ at t/010dependencies.t line 72.
# Can't locate Pod/Coverage.pm in @INC (you may need to install the Pod::Coverage module) (@INC contains: t lib C:/Perl64/lib C:/Perl64/site/lib .) at t/011pod.t line 21.
# BEGIN failed--compilation aborted at t/011pod.t line 21.

# Failed test 't/011pod.t'
# at t/001compile.t line 62.
# --ERROR
# Looks like you failed 1 test of 231.
t/001compile.t .......
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/231 subtests
(less 10 skipped subtests: 220 okay)
t/002goodperl.t ...... ok
t/003safesys.t ....... ok
t/004template.t ...... ok
t/005whitespace.t .... ok
t/006spellcheck.t .... ok
t/007util.t .......... ok
t/008filter.t ........ ok
t/009bugwords.t ...... ok
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE [^}]+}/ at t/010dependencies.t line 72.
t/010dependencies.t .. ok
Can't locate Pod/Coverage.pm in @INC (you may need to install the Pod::Coverage module) (@INC contains: t lib C:/Perl64/lib C:/Perl64/site/lib .) at t/011pod.t line 21.
BEGIN failed--compilation aborted at t/011pod.t line 21.
t/011pod.t ...........
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/012throwables.t .... ok
t/013dbschema.t ...... ok

Test Summary Report
-------------------
t/001compile.t (Wstat: 256 Tests: 231 Failed: 1)
Failed test: 229
Non-zero exit status: 1
t/011pod.t (Wstat: 512 Tests: 0 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
Files=13, Tests=5744, 703 wallclock secs ( 1.88 usr + 0.17 sys = 2.05 CPU)
Result: FAIL
Uncaught exception from user code:
Failed 2/13 test programs. 1/5744 subtests failed.
Test::Harness::runtests("t/001compile.t", "t/002goodperl.t", "t/003safesys.t", "t/004template.t", "t/005whitespace.t", "t/006spellcheck.t", "t/007util.t", "t/008filter.t", ...) called at runtests.pl line 30

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks,
Phil
Thorsten Schöning
2018-06-26 14:18:26 UTC
Permalink
Guten Tag Philip Parsons (Velindre - Medical Physics),
Post by Philip Parsons (Velindre - Medical Physics)
I've had to perform a restore of Bugzilla and since doing so I'm
finding that it's takes 5 to 10 seconds to open a page
What exactly did you restore, Bugzilla, database, web server,
everything of those, only some? If you did not restore 100 %
everything as before, have a look at those things you didn't restore
first. Your description very likely sounds like network related
problems e.g. regarding DNS, so check your web server config, how
clients access your Bugzilla, try to use Bugzilla locally on the
server etc.

Keep in mind that Bugzilla uses its database using TCP/IP by default
as well and it almost always queries the database to e.g. read user
preferences, to know whichs earches are available for the current
user at all etc. So network related problems are not only possible
between your users and the web server, but on the server between web
server and database as well.

Formerly used mod_perl vs. now not could be a problem as well,
Perl-CGI is with a reasonable complex web app is very slow on Windows
withtout mod_perl mostly.

If you didn't restore your web server config, those changes could
easily slip in while everythign seems to work fine.
Post by Philip Parsons (Velindre - Medical Physics)
After a click nothing happens for that time and then
the page displays very quickly. It previously was much quicker than
this.
DNS vs. e.g. mod_perl problems can be seen on the server on things
like CPU load, if there's nothing happending on the server, it's more
liekly to be network related of some kind. So have a look at server
side monitoring as well, especially CPU and network/disk I/O.
Post by Philip Parsons (Velindre - Medical Physics)
I've run runtests.pl (see below).
I pretty much doubt that runtests will be of much help, but if at all
the fact that you can't reach Activestate might be of interest. I can
reach that server properly, but as this is completely outside of your
network, is might have been nocht accessible before as well.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Philip Parsons (Velindre - Medical Physics)
2018-06-26 14:43:58 UTC
Permalink
Hi Thorsten,

Thanks for your quick reply.

I basically restored the c:\bugzilla folder. Db and webserver (IIS) were untouched. I was going to install a second instance of Bugzilla alongside this one and had only run checkconfig.pl and Bugzilla stopped working. I thought I saw something about a perl version issue, so had updated perl to 5.26.1, but this caused more issues, so I managed to find a version online that matched the previous version 5.24.1 and reinstalled that.

Accessing Bugzilla locally (localhost/Bugzilla) doesn't appear to make a difference to speed.

Does this help!?!

Thanks again,
Phil

-----Original Message-----
From: support-bugzilla [mailto:support-bugzilla-bounces+philip.parsons=***@lists.mozilla.org] On Behalf Of Thorsten Schöning
Sent: 26 June 2018 15:18
To: support-***@lists.mozilla.org
Subject: Re: bugzilla page loading very slow
Post by Philip Parsons (Velindre - Medical Physics)
I've had to perform a restore of Bugzilla and since doing so I'm
finding that it's takes 5 to 10 seconds to open a page
What exactly did you restore, Bugzilla, database, web server, everything of those, only some? If you did not restore 100 % everything as before, have a look at those things you didn't restore first. Your description very likely sounds like network related problems e.g. regarding DNS, so check your web server config, how clients access your Bugzilla, try to use Bugzilla locally on the server etc.

Keep in mind that Bugzilla uses its database using TCP/IP by default as well and it almost always queries the database to e.g. read user preferences, to know whichs earches are available for the current user at all etc. So network related problems are not only possible between your users and the web server, but on the server between web server and database as well.

Formerly used mod_perl vs. now not could be a problem as well, Perl-CGI is with a reasonable complex web app is very slow on Windows withtout mod_perl mostly.

If you didn't restore your web server config, those changes could easily slip in while everythign seems to work fine.
Post by Philip Parsons (Velindre - Medical Physics)
After a click nothing happens for that time and then the page displays
very quickly. It previously was much quicker than this.
DNS vs. e.g. mod_perl problems can be seen on the server on things like CPU load, if there's nothing happending on the server, it's more liekly to be network related of some kind. So have a look at server side monitoring as well, especially CPU and network/disk I/O.
Post by Philip Parsons (Velindre - Medical Physics)
I've run runtests.pl (see below).
I pretty much doubt that runtests will be of much help, but if at all the fact that you can't reach Activestate might be of interest. I can reach that server properly, but as this is completely outside of your network, is might have been nocht accessible before as well.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

_______________________________________________
support-bugzilla mailing list
support-***@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-***@lists.mozilla.org in the To: field when you reply.
Thorsten Schöning
2018-06-26 15:12:49 UTC
Permalink
Guten Tag Philip Parsons (Velindre - Medical Physics),
Post by Philip Parsons (Velindre - Medical Physics)
Does this help!?!
It's a start, but check the other things I've mentioned like CPU load,
connection to your database, have a look at web server logs etc. in
the worst case you even need to run Wireshark and have a look at long
running connections or such.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Philip Parsons (Velindre - Medical Physics)
2018-06-26 15:36:32 UTC
Permalink
Thanks Thorsten.

When I click on a link in Bugzilla, it appears to be using a reasonable amount of CPU on the server (perl5.24.1.exe) appears to be using about 50% of the CPU.

I've got IIS set to use cgi. I didn't really understand your comments about mod_perl.

I can't see any errors in the IIS logfiles.

As for network connection, I don't think this is a problem. It's running on a VM, but everything else is running without any noticeable issues.

I haven't done anything to the db as far as I'm aware, but I'm not entirely sure what checksetup.pl does or how it could have broken the installation in the first place.

Thanks again for your help.
Phil.

-----Original Message-----
From: support-bugzilla [mailto:support-bugzilla-bounces+philip.parsons=***@lists.mozilla.org] On Behalf Of Thorsten Schöning
Sent: 26 June 2018 16:13
To: support-***@lists.mozilla.org
Subject: Re: bugzilla page loading very slow
Post by Philip Parsons (Velindre - Medical Physics)
Does this help!?!
It's a start, but check the other things I've mentioned like CPU load, connection to your database, have a look at web server logs etc. in the worst case you even need to run Wireshark and have a look at long running connections or such.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

_______________________________________________
support-bugzilla mailing list
support-***@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-***@lists.mozilla.org in the To: field when you reply.
Thorsten Schöning
2018-06-26 17:08:39 UTC
Permalink
Guten Tag Philip Parsons (Velindre - Medical Physics),
Post by Philip Parsons (Velindre - Medical Physics)
When I click on a link in Bugzilla, it appears to be using a
reasonable amount of CPU on the server (perl5.24.1.exe) appears to be using about 50% of the CPU.
When does it start to use CPU, how long does it do regarding showing
HTML in the browser etc.? In case of network problems there would be
very likely some drop in CPU-usage for some seconds. If it takes 50 %
all the time, my guess would be that everything works as intended
instead. If you think it's too slow, check other data like disk I/O
and stuff, but Perl CGI especially under Windows is slow.

I often use Process Monitor to see what some app does in the file
system in those cases:

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

Bugzilla e.g. generates CSS/JS data on the fly and caches that in some
directories, maybe you have permissions problems and Bugzilla is doing
that more often than expected.
Post by Philip Parsons (Velindre - Medical Physics)
I've got IIS set to use cgi. I didn't really understand your
comments about mod_perl.
mod_perl makes Bugzilla fast on Windows and you said that it was fast
before. Without mod_perl Bugzilla is very likely do be reasonable
slow, therefore I suggested to check your setup regarding this. If you
didn't change anything in the web server, mod_perl most likely would
have still been enabled if it was before, but you have problems, so
need to check everything. OTOH, in my opinion it's pretty unlikely
that you had mod_perl running on Windows anyway. It's pretty uncommon
to use with IIS, if possible at all.
Post by Philip Parsons (Velindre - Medical Physics)
I haven't done anything to the db as far as I'm aware, but I'm not
entirely sure what checksetup.pl does or how it could have broken
the installation in the first place.
That's another topic and without knowing what you have done exactly...
But checksetup.pl doesn't magically slows down your database or
changes network related stuff, so in my opinion it's most likely not
related to that specifically.

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Loading...