Possibly only for me, but I thought I'd report that Trac is very slow to load at the moment: https://trac.osgeo.org/geotiff/
-jeff
--
Jeff McKenna
President Emeritus, OSGeo Foundation
http://wiki.osgeo.org/wiki/Jeff_McKenna
On Nov 28, 2016 2:55 PM, “Jeff McKenna” <jmckenna@gatewaygeomatics.com> wrote:
Possibly only for me, but I thought I’d report that Trac is very slow to load at the moment: https://trac.osgeo.org/geotiff/
This is a known issue… Probably the apache config needs a review (see the earlier discussion from some days ago).
I checked the server-status page on the machine but don’t know what to tune.
Markus
-jeff
–
Jeff McKenna
President Emeritus, OSGeo Foundation
http://wiki.osgeo.org/wiki/Jeff_McKenna
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
On Mon, Nov 28, 2016 at 03:09:46PM +0100, Markus Neteler wrote:
On Nov 28, 2016 2:55 PM, "Jeff McKenna" <jmckenna@gatewaygeomatics.com>
wrote:
>
> Possibly only for me, but I thought I'd report that Trac is very slow to
load at the moment: https://trac.osgeo.org/geotiff/This is a known issue... Probably the apache config needs a review (see the
earlier discussion from some days ago).I checked the server-status page on the machine but don't know what to tune.
Is the status page any useful at understanding *which* service is
being slow ?
One thing I know I did for sure was to (long ago) raising logging
levels. Maybe reducing them would help a bit ? See /etc/trac and
/var/log/trac
--strk;
On Mon, Nov 28, 2016 at 4:13 PM, Sandro Santilli <strk@kbt.io> wrote:
On Mon, Nov 28, 2016 at 03:09:46PM +0100, Markus Neteler wrote:
On Nov 28, 2016 2:55 PM, “Jeff McKenna” <jmckenna@gatewaygeomatics.com>
wrote:Possibly only for me, but I thought I’d report that Trac is very slow to
load at the moment: https://trac.osgeo.org/geotiff/This is a known issue… Probably the apache config needs a review (see the
earlier discussion from some days ago).I checked the server-status page on the machine but don’t know what to tune.
Is the status page any useful at understanding which service is
being slow ?
Probably (BTW: I made a screenshot and then used “gocr” to be able to copy-paste it here. IPs xx’ed and also version numbers):
neteler@tracsvn:~$ links http://localhost/server-status
Apache Server Status for localhost
Server Version: Apache/2.xxxx [version omitted for the mailing list archive]
Server Built: [version omitted for the mailing list archive]
Current Time: monday, 28-Nov-2016 09:49:03 PST
Restart Time: Saturday, 26-Nov-2016 06:09:06 PST
Parent Server Generation: 1
Server uptime: 2 days 3 hours 39 minutes 56 seconds
Total accesses: 798705 - Total Traffic: 45.1 GB
CPU Usage: u47.77 s3.01 cu.12 cs0 - .0274_ CPU load
4.29 requests/sec - 254.0 kB/second - 59.2 kB/request
5 requests currently being processed, 10 idle workers
K…WC_C_K…
Scoreboard Key:
___ Waiting for Connection, S Starting up, n Reading Request,
W Sending Reply, K Keepalive ( read) , D DNS Lookup,
C Closing connection, L Logging, G Gracefully finishing,
I Idle cleanup of worker, _. _ Open slot with no current process
Srv PID Acc m CPU SS Req Conn Child Slot Client VHost Request
0-1 24347 0/11/42190 _ 0.02 0 165 0.0 0.00 1926.83 xx.74.170.ww git.osgeo.org NULL
1-1 24364 1/1/41394 K 1.30 0 1325 0.2 0.00 1972.41 xx.143.71.ww trac.osgeo.org GET /openlayers/chrome/common/collapsed.png HTTP/1 1
2-1 24288 0/7/40752 _ 2.37 4 159 0.0 0.06 1633.89 xx.143.71.ww git.osgeo.org NULL
3-1 - 0/0/41000 4.22 1 61 0.0 0.00 1090.36 xx.143.71.ww git.osgeo.org NULL
9-1 - 0/0/39910 2.67 1 69 0.0 0.00 3059.53 xx.143.71.ww git.osgeo.org NULL
5-1 - 0/0/39344 3.27 0 1972 0.0 0.00 2294.13 xx.46.52.zz trac.osgeo.org GET /geos/timeline?from=2013-06-27T06_3A22_3A01-07_3A00@precisi
6-1 - 0/0/38860 2.46 1 63 0.0 0.00 1726.96 xx.143.71.ww git.osgeo.org NULL
7-1 24293 0/4/39105 _ 1.33 1 2 0.0 0.01 1035.16 xx.255.250.pp git.osgeo.org NULL
8-1 24350 0/1/38107 W 1.85 0 0 0.0 0.01 2328.70 127.0.0.1 git.osgeo.org GET /server-status HTTP/1.1
9-1 24351 1/8/37419 C 1.95 0 1998 9.8 0.01 1647.76 xx.125.71.hh trac.osgeo.org GET /gdal/log/trunk/gdal/port/cpl_vsil.cpp?rev=30823 HTTP/1 1
10-1 24353 0/2/35222 0.00 1 0 0.0 0.00 3315.85 xx.154.133.ee git.osgeo.org NULL
In this very moment the load level is low.
I suspect that the git.osgeo.org traffic not not sufficiently supported with the current apache configuration.
One thing I know I did for sure was to (long ago) raising logging
levels. Maybe reducing them would help a bit ? See /etc/trac and
/var/log/trac
Could also be!
Markus
–
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
On 11/28/2016 09:56 AM, Markus Neteler wrote:
On Mon, Nov 28, 2016 at 4:13 PM, Sandro Santilli <strk@kbt.io> wrote:
On Mon, Nov 28, 2016 at 03:09:46PM +0100, Markus Neteler wrote:
On Nov 28, 2016 2:55 PM, "Jeff McKenna" <jmckenna@gatewaygeomatics.com>
wrote:Possibly only for me, but I thought I'd report that Trac is very slow
to
load at the moment: https://trac.osgeo.org/geotiff/
This is a known issue... Probably the apache config needs a review (see
the
earlier discussion from some days ago).
I checked the server-status page on the machine but don't know what to
tune.
Is the status page any useful at understanding *which* service is
being slow ?Probably (BTW: I made a screenshot and then used "gocr" to be able to
copy-paste it here. IPs xx'ed and also version numbers):neteler@tracsvn:~$ links http://localhost/server-status
Apache Server Status for localhost
Server Version: Apache/2.xxxx [version omitted for the mailing list
archive]Server Built: [version omitted for the mailing list archive]
Current Time: monday, 28-Nov-2016 09:49:03 PST
Restart Time: Saturday, 26-Nov-2016 06:09:06 PST
Parent Server Generation: 1
Server uptime: 2 days 3 hours 39 minutes 56 seconds
Total accesses: 798705 - Total Traffic: 45.1 GB
CPU Usage: u47.77 s3.01 cu.12 cs0 - .0274_ CPU load
4.29 requests/sec - 254.0 kB/second - 59.2 kB/request
5 requests currently being processed, 10 idle workers_K_...._WC_C_K_.............................................
Scoreboard Key:
___ Waiting for Connection, _S_ Starting up, _n_ Reading Request,
_W_ Sending Reply, _K_ Keepalive ( read) , _D_ DNS Lookup,
_C_ Closing connection, _L_ Logging, _G_ Gracefully finishing,
_I_ Idle cleanup of worker, _. _ Open slot with no current processSrv PID Acc m CPU SS Req Conn Child Slot Client VHost
Request
0-1 24347 0/11/42190 _ 0.02 0 165 0.0 0.00 1926.83 xx.74.170.ww
git.osgeo.org NULL
1-1 24364 1/1/41394 K 1.30 0 1325 0.2 0.00 1972.41 xx.143.71.ww
trac.osgeo.org GET /openlayers/chrome/common/collapsed.png HTTP/1 1
2-1 24288 0/7/40752 _ 2.37 4 159 0.0 0.06 1633.89 xx.143.71.ww
git.osgeo.org NULL
3-1 - 0/0/41000 4.22 1 61 0.0 0.00 1090.36 xx.143.71.ww
git.osgeo.org NULL
9-1 - 0/0/39910 2.67 1 69 0.0 0.00 3059.53 xx.143.71.ww
git.osgeo.org NULL
5-1 - 0/0/39344 3.27 0 1972 0.0 0.00 2294.13 xx.46.52.zz
trac.osgeo.org GET
/geos/timeline?from=2013-06-27T06_3A22_3A01-07_3A00@precisi
6-1 - 0/0/38860 2.46 1 63 0.0 0.00 1726.96 xx.143.71.ww
git.osgeo.org NULL
7-1 24293 0/4/39105 _ 1.33 1 2 0.0 0.01 1035.16 xx.255.250.pp
git.osgeo.org NULL
8-1 24350 0/1/38107 W 1.85 0 0 0.0 0.01 2328.70 127.0.0.1
git.osgeo.org GET /server-status HTTP/1.1
9-1 24351 1/8/37419 C 1.95 0 1998 9.8 0.01 1647.76 xx.125.71.hh
trac.osgeo.org GET /gdal/log/trunk/gdal/port/cpl_vsil.cpp?rev=30823 HTTP/1 1
10-1 24353 0/2/35222 0.00 1 0 0.0 0.00 3315.85 xx.154.133.ee
git.osgeo.org NULLIn this very moment the load level is low.
I suspect that the git.osgeo.org traffic not not sufficiently supported
with the current apache configuration.One thing I know I did for sure was to (long ago) raising logging
levels. Maybe reducing them would help a bit ? See /etc/trac and
/var/log/tracCould also be!
Markus
Are all the apache logs in one log? If so, download the last rotate and do some parsing and counting of what's being hit (simple graphs grouped by the trac instance top level name should work). If they are separate logs, then just see which one is significantly bigger.
Is the git on the same machine, should be easy enough to send that to it's own log if it's a separate vhost.
-Alex
On Mon, Nov 28, 2016 at 05:09:10PM -0800, Alex Mandel wrote:
If they are separate logs, then
just see which one is significantly bigger.
Here's the sorted list:
183001555 Nov 27 06:29 trac-access.log.1
53632291 Nov 27 06:26 git-ssl-access.log.1
45873446 Nov 27 06:25 svn-access.log.1
41824434 Nov 27 06:25 trac-ssl-access.log.1
38420594 Nov 27 06:29 error.log.1
21302076 Nov 27 06:25 svn-ssl-access.log.1
16990525 Nov 27 06:25 other_vhosts_access.log.1
2077906 Nov 27 06:24 svn-error.log.1
1837492 Nov 27 06:23 trac-error.log.1
1461950 Nov 27 06:26 git-access.log.1
1309253 Nov 27 06:25 trac-ssl-error.log.1
769825 Nov 27 06:23 git-ssl-error.log.1
366315 Nov 27 06:23 svn-ssl-error.log.1
14541 Jun 7 2010 access.log.1
479 Nov 26 09:30 git-error.log.1
It's interesting to see that trac gets more http than https,
shouldn't they all redirected to http ? A random one I picked
(last line in the log) is a download of a 48.9 MB .zip file
requested by a bot:
"Baiduspider/2.0; +http://www.baidu.com/search/spider.html"
Trying that url shows it's indeed not redirected.
I don't know how does this relate to the performance issues, if
at all, but in any case I guess it's something that could be
looked into (both forbidding spiders to download zip files
and reviewing automatic redirect to https).
# grep 'format=zip' trac-ssl-access.log.1 | wc -l
519
# grep 'format=zip' trac-access.log.1 | wc -l
10849
A quick look at the error log reports robots.txt isn't found.
--strk;
On Tue, Nov 29, 2016 at 07:39:58AM +0100, Sandro Santilli wrote:
A quick look at the error log reports robots.txt isn't found.
I've fixed this, a file existed but was in the wrong directory,
I moved it to the correct place and left now, let's see if things
change noticeably.
--strk;
On Nov 29, 2016 7:46 AM, “Sandro Santilli” <strk@kbt.io> wrote:
On Tue, Nov 29, 2016 at 07:39:58AM +0100, Sandro Santilli wrote:
A quick look at the error log reports robots.txt isn’t found.
I’ve fixed this, a file existed but was in the wrong directory,
I moved it to the correct place and left now, let’s see if things
change noticeably.
https://trac.osgeo.org/robots.txt
Does this mean that all except for tickets and wikis is excluded from indexing? Just to understand the policy.
Thanks
Markus
–strk;
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
On Tue, Nov 29, 2016 at 07:53:11AM +0100, Markus Neteler wrote:
On Nov 29, 2016 7:46 AM, "Sandro Santilli" <strk@kbt.io> wrote:
>
> On Tue, Nov 29, 2016 at 07:39:58AM +0100, Sandro Santilli wrote:
>
> > A quick look at the error log reports robots.txt isn't found.
>
> I've fixed this, a file existed but was in the wrong directory,
> I moved it to the correct place and left now, let's see if things
> change noticeably.https://trac.osgeo.org/robots.txt
Does this mean that all except for tickets and wikis is excluded from
indexing? Just to understand the policy.
I didn't make the policy, just copied an existing file.
I think the current config means code is excluded indeed.
Don't know where that policy originates from, nor how we're
supposed to keep it in sync for all projects or whether the
configuration should be the same for all.
--strk;
On Tue, Nov 29, 2016 at 07:56:41AM +0100, Sandro Santilli wrote:
Don't know where that policy originates from, nor how we're
supposed to keep it in sync for all projects or whether the
configuration should be the same for all.
I found out there are instruction on the wiki about generating
the robots.txt file upon creating a new trac project, see
https://wiki.osgeo.org/wiki/Trac_Instances
I just reviewed the script to create the robots.txt in the correct
place, and added it to the local git repo. The script contains
no comment referencing policy making discussions.
--strk;
On Tue, Nov 29, 2016 at 07:56:41AM +0100, Sandro Santilli wrote:
I didn't make the policy, just copied an existing file.
Suggested tipical robots.txt for trac is found in the RobotsTxt
trac plugin page:
https://trac-hacks.org/wiki/RobotsTxtPlugin
The suggestion is:
User-agent: *
Disallow: /browser
Disallow: /log
Disallow: /changeset
Disallow: /report
Disallow: /newticket
Disallow: /search
Our configuration is missing "newticket" and "search" while it is
adding "query", "timeline", "doxygen" (?), attachment.
--strk;