| [01:03:16] |
* |
pthread has quit IRC |
| [01:11:51] |
* |
pygi has joined #trac |
| [01:55:17] |
* |
xjjk has quit IRC |
| [02:05:57] |
* |
m_g has joined #trac |
| [02:09:13] |
* |
__doc__ has joined #trac |
| [02:09:54] |
<__doc__> |
hi, a question. trac has this error reporting facility, I think that's pretty handy, how can I build it into my own web project? |
| [02:10:06] |
* |
ktne has joined #trac |
| [02:11:02] |
<__doc__> |
ic |
| [02:11:07] |
<__doc__> |
it's /trac/newticket?summary=Compile%20Error&version=1.0&component=gui etc. |
| [02:12:55] |
* |
maxb has joined #trac |
| [02:21:53] |
* |
kmccabe has quit IRC |
| [02:52:07] |
* |
gak has joined #trac |
| [03:01:59] |
* |
gakman has quit IRC |
| [03:21:08] |
* |
mario_ has joined #trac |
| [03:21:53] |
* |
pygi has quit IRC |
| [03:21:56] |
* |
mario_ is now known as pygi |
| [03:32:00] |
* |
blinx has joined #trac |
| [03:39:22] |
* |
pombreda has joined #trac |
| [04:01:33] |
* |
Cream^ has joined #trac |
| [04:13:49] |
* |
pombreda has quit IRC |
| [05:01:53] |
* |
mfuchs has joined #trac |
| [05:12:25] |
* |
mfuchs has quit IRC |
| [05:59:15] |
* |
stretch has joined #trac |
| [05:59:29] |
* |
stretch has quit IRC |
| [06:06:36] |
* |
efuzzyone has joined #trac |
| [06:06:58] |
<efuzzyone> |
hi, are there any guidelines on moving trac from one machine to another? |
| [06:07:15] |
<coderanger> |
Just move the env folder |
| [06:07:32] |
<efuzzyone> |
coderanger: thanks |
| [06:07:37] |
<coderanger> |
one the other side make sure that templates_dir and repository_dir are corret |
| [06:07:45] |
<coderanger> |
but thats about it |
| [06:08:01] |
<efuzzyone> |
will the tickets and the wiki content all move? |
| [06:08:20] |
<coderanger> |
yep |
| [06:08:24] |
<coderanger> |
assuming you use sqlite |
| [06:08:40] |
<coderanger> |
if you are using a server-based DB, you will need to use their dump/reload tools |
| [06:08:40] |
<efuzzyone> |
great, thanks it does |
| [06:09:39] |
* |
FauxFaux has joined #trac |
| [06:16:50] |
* |
[algo] has joined #trac |
| [06:17:36] |
<[algo]> |
Somehow trac fcgi is very slow |
| [06:17:55] |
* |
djwonk has joined #trac |
| [06:18:02] |
<[algo]> |
any reasons why it can be so ? |
| [06:33:54] |
* |
pombreda has joined #trac |
| [06:34:56] |
<efuzzyone> |
coderanger: i am getting DatabaseError: file is encrypted or is not a database |
| [06:35:22] |
<coderanger> |
efuzzyone: You changed sqlite versions between the two boxes |
| [06:35:29] |
<efuzzyone> |
maybe |
| [06:35:36] |
<efuzzyone> |
let me check |
| [06:35:47] |
<coderanger> |
you can do a dump/reload |
| [06:35:52] |
<coderanger> |
see the TracUpgrade page |
| [06:39:58] |
<[algo]> |
can that be because of clearsilver ? |
| [06:49:51] |
* |
djwonk has quit IRC |
| [06:51:34] |
* |
Epcylon has quit IRC |
| [06:51:57] |
* |
frankg has quit IRC |
| [06:55:06] |
<coderanger> |
[algo]: The slowness? |
| [06:55:15] |
* |
Epcylon has joined #trac |
| [06:55:23] |
* |
pombreda has quit IRC |
| [06:55:37] |
<coderanger> |
[algo]: Check that the fcgi daemon is running |
| [07:10:04] |
<[algo]> |
wow |
| [07:10:08] |
<[algo]> |
hm no daemon |
| [07:10:36] |
<coderanger> |
is this on a shared host? |
| [07:10:38] |
<[algo]> |
well |
| [07:10:43] |
<[algo]> |
it died because of inactivity |
| [07:10:45] |
<[algo]> |
I restarted it |
| [07:10:49] |
<[algo]> |
asked Timeline |
| [07:10:58] |
<[algo]> |
checked that daemon is running before request |
| [07:11:05] |
<[algo]> |
and fastcgi worked long |
| [07:11:10] |
<[algo]> |
and ate lots of CPU |
| [07:12:48] |
<[algo]> |
I reload timeline |
| [07:12:49] |
<[algo]> |
again |
| [07:12:50] |
<[algo]> |
same |
| [07:16:01] |
<coderanger> |
what version is this? |
| [07:16:15] |
<[algo]> |
10 |
| [07:16:28] |
<coderanger> |
what specific version .. |
| [07:16:32] |
<[algo]> |
a moment |
| [07:16:45] |
<[algo]> |
Trac 0.10rc1... |
| [07:17:14] |
<coderanger> |
You might want to upgrade to an actual release :P |
| [07:17:23] |
<[algo]> |
0.10.x ? |
| [07:17:35] |
<coderanger> |
0.10.3 is current |
| [07:17:38] |
<[algo]> |
I've got a couple of pathces, jabber notifications |
| [07:17:42] |
* |
Dortly has joined #trac |
| [07:18:11] |
<Dortly> |
guys i'm getting the following in my apache error log: http://pastebin.ca/289925 |
| [07:18:23] |
<Dortly> |
i'm trying to serve trac via apache/http |
| [07:18:38] |
<coderanger> |
Dortly: Okay, does it have permission ... |
| [07:18:40] |
<[algo]> |
hm, I'll debug what takes so long :/ |
| [07:19:26] |
<coderanger> |
[algo]: I seem to remember issues with rc1 and the included WSGI->FCGI bridge |
| [07:19:49] |
<coderanger> |
It was fixed by getting the latest copy of the bridger module |
| [07:22:09] |
<[algo]> |
bridger python module ? |
| [07:22:21] |
<[algo]> |
any particular name ? |
| [07:22:27] |
<[algo]> |
I have gentoo, can emerge it maybe |
| [07:22:37] |
<coderanger> |
No |
| [07:23:05] |
<coderanger> |
its integrated into Trac |
| [07:23:06] |
<Dortly> |
this is my vhost:http://pastebin.ca/289928 |
| [07:23:38] |
<coderanger> |
Dortly: Thats fine, but what are the permissions on the db folder |
| [07:24:34] |
<Dortly> |
-rw-r--r-- 1 ahousley ahousley 1007616 Dec 23 14:56 trac.db |
| [07:24:59] |
<coderanger> |
Dortly: So apache doesn't have read/write access :P |
| [07:25:06] |
<coderanger> |
Reading error messages ftw |
| [07:25:12] |
<Dortly> |
drwxr-xr-x 2 ahousley ahousley 4096 Dec 23 14:56 db |
| [07:25:27] |
<coderanger> |
Does apache run as "ahousley"? |
| [07:25:30] |
<[algo]> |
should I try 0.11 ? |
| [07:25:45] |
<coderanger> |
[algo]: If you are going to upgrade, why not use a stable release? |
| [07:25:57] |
<[algo]> |
ok |
| [07:25:57] |
<Dortly> |
don't think so... is there a way to find out? |
| [07:26:12] |
<Dortly> |
could i just chmod 755 the db? |
| [07:26:24] |
<m_g> |
is anybody aware of the following authentication problem: user is able to log in, but if he edits a ticket or adds a milestone or whatever he gets 'forbidden' and has to retry it several times before it works again? the user has TRAC_ADMIN |
| [07:26:34] |
<coderanger> |
Dortly: chgrp -R apache /path/to/env |
| [07:26:46] |
<coderanger> |
Dortly: chmod -R g+rw /path/to/env |
| [07:29:01] |
<Dortly> |
thanks coderanger, you saved the day! merry xmas :-) |
| [07:47:07] |
<blinx> |
how can I save memory with trac? |
| [08:06:55] |
* |
idnar has quit IRC |
| [08:06:58] |
* |
idnar_ has joined #trac |
| [08:16:25] |
<[algo]> |
hello idnar |
| [08:24:05] |
* |
Tim_ has joined #trac |
| [08:25:47] |
* |
Tim_ has left #trac |
| [08:28:00] |
* |
[algo] has quit IRC |
| [08:39:50] |
* |
converter has joined #trac |
| [08:48:20] |
* |
efuzzyone has quit IRC |
| [09:13:04] |
* |
converter has quit IRC |
| [09:33:10] |
* |
boorad has joined #trac |
| [09:52:00] |
* |
pthread has joined #trac |
| [10:23:45] |
<s0undt3ch> |
coderanger: arround, is there a way we can import a file based on it's path? |
| [10:25:09] |
<s0undt3ch> |
nevermind |
| [10:32:15] |
<s0undt3ch> |
ok, can we load setup info from a project using setuptools but not yet installed in site-packages? |
| [10:37:21] |
* |
pthread has quit IRC |
| [10:43:37] |
* |
pyjamamama has left #trac |
| [10:47:55] |
<pacopablo> |
s0undt3ch: look at trac.loader |
| [10:49:39] |
<s0undt3ch> |
pacopablo: I've been looking at setup tools code, but I'll look at that too, thanks |
| [10:51:07] |
<s0undt3ch> |
pacopablo: I actually don't want to load it, just want to access the package's metadata |
| [10:55:45] |
<pacopablo> |
no clue then |
| [10:55:55] |
<pacopablo> |
I"m sure it can be done, I just haven't done it before |
| [10:57:20] |
<s0undt3ch> |
pacopablo: it can |
| [10:57:26] |
<s0undt3ch> |
from pkg_resources import find_distributions |
| [10:57:32] |
<s0undt3ch> |
for d in find_distributions(self.basedir, only=True): |
| [10:57:37] |
<s0undt3ch> |
print d.project_name |
| [10:57:48] |
<s0undt3ch> |
that get's me the name of the distribution |
| [10:58:19] |
<Dortly> |
when i click on a php file in browse source in trac i get the following: HTML preview not available |
| [10:58:33] |
<Dortly> |
do i need to install something separately so that php files may be read? |
| [10:58:55] |
<coderanger> |
php |
| [10:59:11] |
<Dortly> |
hmm... php is installed... |
| [10:59:21] |
<coderanger> |
you need to command line version |
| [10:59:30] |
<coderanger> |
and check that the php_path is set correctly |
| [10:59:58] |
<Dortly> |
i need to cli php so that the source can be viewed in trac source browser? |
| [11:00:03] |
<Dortly> |
where is the php_path too? |
| [11:00:07] |
<coderanger> |
trac.ini |
| [11:00:14] |
<coderanger> |
I think SliverCity can do PHP too |
| [11:00:17] |
<coderanger> |
and Pygments |
| [11:00:28] |
<Dortly> |
yeah i was thinking about SilverCity |
| [11:00:40] |
<coderanger> |
There is a list on the wiki page |
| [11:00:42] |
<Dortly> |
got to eat dinner now and will get back to it |
| [11:00:43] |
<Dortly> |
thanks |
| [11:27:04] |
<Dortly> |
in my trac.ini, php_path = php |
| [11:27:39] |
<Dortly> |
at the shell simply typing "php --version" gives the version no, so is this correct? e.g. what i need to view the php source from within trac..? |
| [11:30:01] |
<coderanger> |
is that the GCI or CLI version though] |
| [11:34:08] |
<neuralis> |
coderanger: get my mail the other day? |
| [11:34:34] |
<coderanger> |
neuralis: Just got it about an hour ago. My email has been going a bit crazy the last few day |
| [11:35:02] |
<coderanger> |
neuralis: Making a slightly nicer one and then I'll email it to you |
| [11:35:26] |
<neuralis> |
coderanger: sounds good |
| [11:35:58] |
<coderanger> |
IMAP + Mail.app + low speed connection = boom :( |
| [11:43:10] |
<Dortly> |
cli |
| [11:43:46] |
<Dortly> |
PHP 5.2.0 (cli) |
| [11:44:58] |
<coderanger> |
Dortly: Try giving the full path |
| [11:45:26] |
* |
stevegt has joined #trac |
| [11:47:03] |
<Dortly> |
yeah that did the trick - /usr/local/bin/php instead of just php |
| [11:47:09] |
<Dortly> |
and the syntax is highlighted!! |
| [11:47:36] |
<coderanger> |
if you feel adventurous you can play with the pygments plugin |
| [11:47:54] |
<coderanger> |
I hear it does funky stuff for PHP coloring |
| [11:48:41] |
* |
prisoner has joined #trac |
| [11:54:39] |
<prisoner> |
trac-hacks talks about moving away from mod_python to fastcgi. does anyone know if this is unique to them or is trac moving in that direction as a whole? |
| [11:55:25] |
<prisoner> |
The reason I ask is that I used mod_python in my project: http://www.rubystarman.org/ |
| [11:55:43] |
<coderanger> |
Well its mostly to get away from Apache |
| [11:55:55] |
<coderanger> |
Since Apache has issues under heavy load |
| [11:56:26] |
<coderanger> |
t-h used to be very slow, but it ended up being a misconfigured vserver more than FCGI vs. mod_python |
| [11:56:27] |
<prisoner> |
ahh, makes sense, so a similar problem to when the rails folks are dealing with |
| [11:56:47] |
<coderanger> |
Yes, t.e.o moved to Lighty not long ago |
| [11:57:02] |
<coderanger> |
and pacopablo now swears by tracd+nginx |
| [11:57:15] |
<coderanger> |
so there is some question as to how best to run a high-traffic Trac site |
| [11:58:02] |
<prisoner> |
I wonder if running a pool of servers and using mod_proxy_balancer would be as useful here as it is in rails |
| [11:58:18] |
<coderanger> |
thats the same idea as the nginx solution |
| [11:58:25] |
<prisoner> |
nod |
| [11:58:27] |
<coderanger> |
except s/mongrel/tracd/ |
| [11:59:03] |
<coderanger> |
OTOH I run all my sites (*.coderanger.net) on mod_python |
| [11:59:11] |
<coderanger> |
and have it nicely tweaked |
| [12:00:14] |
<coderanger> |
I've yet to see any concrete numbers with all these, so its mostly by hearsay |
| [12:01:42] |
<prisoner> |
was there any tweak in particular you found most useful? |
| [12:02:15] |
<coderanger> |
http://coderanger.net/~coderanger/httpd/httpd.conf |
| [12:02:24] |
<coderanger> |
the settings for mpm_worker |
| [12:02:51] |
<coderanger> |
basically I run everything inside a single worker process |
| [12:03:04] |
<prisoner> |
when I built the trac parts of starman there didn't seem to be many things to tweak. ahh, yes, those setting are soon to be tackled by starman! |
| [12:03:22] |
<coderanger> |
Since the env cache is per-process, you want to minimize those |
| [12:03:50] |
<prisoner> |
I assume you use prefork? |
| [12:03:56] |
<coderanger> |
no |
| [12:03:59] |
<coderanger> |
worker |
| [12:04:08] |
<coderanger> |
I want as few processes as possible |
| [12:04:12] |
<coderanger> |
namely 1 |
| [12:04:24] |
<prisoner> |
oh. yes, that is unusual. |
| [12:04:31] |
<coderanger> |
yeah, but for Trac it works well |
| [12:05:38] |
<prisoner> |
MaxRequestsPerChild 10000 -- now that's confidence! |
| [12:06:07] |
<coderanger> |
Its just to keep any leaks in mod_python under control |
| [12:07:09] |
<coderanger> |
Python 2.4 has a persistent leak with the small-string allocation functions |
| [12:07:17] |
<coderanger> |
over time it can build up |
| [12:17:11] |
<asmodai> |
coderanger: hey, but you heard it, we're egoists |
| [12:17:32] |
<coderanger> |
Heh |
| [12:17:40] |
<coderanger> |
gotta love it |
| [12:18:07] |
* |
xjjk has joined #trac |
| [12:18:22] |
<asmodai> |
I am :) |
| [12:18:39] |
<asmodai> |
loving it, and it ain't even McDonalds |
| [12:20:29] |
<coderanger> |
Ronald's lawyers will be contacting you shortly |
| [12:22:17] |
* |
tuxipuxi_ has joined #trac |
| [12:37:19] |
* |
m_g has quit IRC |
| [12:55:32] |
* |
francois-simond has joined #trac |
| [13:11:05] |
* |
djwonk has joined #trac |
| [13:14:59] |
* |
Dortly is now known as Fastly |
| [13:44:10] |
* |
ktne has quit IRC |
| [14:33:29] |
* |
djwonk has left #trac |
| [14:35:42] |
* |
pygi has quit IRC |
| [14:51:33] |
* |
Cream^ has quit IRC |
| [15:06:28] |
* |
_shawn has quit IRC |
| [15:30:31] |
* |
pygi has joined #trac |
| [15:33:14] |
* |
bofh has joined #trac |
| [15:38:37] |
* |
tuxipuxi_ has quit IRC |
| [15:42:46] |
* |
bofh has quit IRC |
| [15:44:35] |
* |
_shawn has joined #trac |
| [16:10:15] |
* |
pygi has quit IRC |
| [16:52:30] |
* |
[algo] has joined #trac |
| [17:22:37] |
<[algo]> |
trac 0.10.3 |
| [17:22:39] |
<[algo]> |
is slow |
| [17:22:44] |
<[algo]> |
trac.fcgi eats lots of CPU |
| [17:24:01] |
<[algo]> |
especially timeline |
| [17:25:39] |
<[algo]> |
how can I profile trac ? |
| [17:48:56] |
* |
miraage has quit IRC |
| [18:06:41] |
* |
__doc__ has quit IRC |
| [18:29:01] |
<[algo]> |
fuck |
| [18:29:07] |
<[algo]> |
templates and parseHTML eat all CPU |
| [18:30:15] |
<prisoner> |
chill. trac needs a fairly modern system |
| [18:31:27] |
<[algo]> |
where did you get such a slow template ? |
| [18:31:33] |
<[algo]> |
engine |
| [18:31:57] |
<[algo]> |
is genshi much faster ? |
| [18:33:10] |
<[algo]> |
should I try 0.11 ? |
| [18:33:23] |
<prisoner> |
describe what you're running it on |
| [18:33:41] |
<prisoner> |
and btw, I just use 10.3, so no idea about the next release |
| [18:33:54] |
<[algo]> |
I'm running on gentoo |
| [18:33:56] |
<[algo]> |
fastcgi |
| [18:34:13] |
<[algo]> |
2 x Xeon box |
| [18:34:19] |
<[algo]> |
but not for trac solely |
| [18:34:43] |
<[algo]> |
I profiled trac |
| [18:34:48] |
<prisoner> |
ok, it should scream on that. you sure fastcgi is running and it's not falling back to CGI |
| [18:34:55] |
<[algo]> |
up to 90% of time is templates |
| [18:35:01] |
<[algo]> |
yeah I'm sure |
| [18:35:58] |
<prisoner> |
most modern web apps spend all their time either waiting on SQL or rendering templates, so that sounds right |
| [18:36:07] |
<[algo]> |
I've got profiling results |
| [18:36:25] |
<[algo]> |
1 0.280 0.280 3.290 3.290 /usr/lib/python2.4/site-packages/trac/ticket/report.py:211(_render_view) |
| [18:36:30] |
<[algo]> |
3 seconds rendering view |
| [18:36:32] |
<[algo]> |
gosh |
| [18:36:38] |
<prisoner> |
is tracd just as slow? |
| [18:36:45] |
<[algo]> |
no |
| [18:36:47] |
<[algo]> |
apache + fastcgi |
| [18:37:00] |
<[algo]> |
LA < 0.7 |
| [18:37:01] |
<prisoner> |
I mean, try tracd and see if it's slow too |
| [18:37:03] |
<[algo]> |
2CPU |
| [18:37:06] |
<[algo]> |
heh |
| [18:37:08] |
<[algo]> |
no matter |
| [18:37:14] |
<[algo]> |
that's same |
| [18:37:18] |
<[algo]> |
I tried mod_python before |
| [18:37:57] |
<[algo]> |
3 seconds for templates |
| [18:37:58] |
<[algo]> |
hm |
| [18:38:03] |
<prisoner> |
I have it running in a linux VM slice on an old P4 under a windows host and I don't see anything near that slow |
| [18:38:04] |
<[algo]> |
maybe something wrong with it ? |
| [18:38:16] |
<[algo]> |
prisoner: how much a page generation takes ? |
| [18:38:49] |
<prisoner> |
things load before I let the mouse button up, so I never bothered looking really |
| [18:40:17] |
<[algo]> |
1 0.280 0.280 3.290 3.290 /usr/lib/python2.4/site-packages/trac/ticket/report.py:211(_render_view) |
| [18:40:18] |
<[algo]> |
1706 0.220 0.000 0.590 0.000 /usr/lib/python2.4/HTMLParser.py:224(parse_starttag) |
| [18:40:18] |
<[algo]> |
4709/4644 0.180 0.000 1.110 0.000 /usr/lib/python2.4/site-packages/trac/web/clearsilver.py:217(add_value) |
| [18:40:18] |
<[algo]> |
1 0.180 0.180 1.220 1.220 /usr/lib/python2.4/HTMLParser.py:132(goahead) |
| [18:40:25] |
<[algo]> |
these are top 4 functions |
| [18:40:32] |
<[algo]> |
is that ok that they are top ? |
| [18:40:44] |
<[algo]> |
maybe caching is disabled somewhere ? |
| [18:43:54] |
<prisoner> |
beats me. sounds unique to your setup there. I'd try it on another system or fresh VM before going any further |
| [18:44:28] |
<prisoner> |
it's not exactly the fastest app, but those numbers look off for sure |
| [18:45:09] |
<[algo]> |
hm hm |
| [18:55:29] |
<coderanger> |
How much CPU are you giving Trac? |
| [18:57:12] |
<[algo]> |
I set no limits |
| [18:57:21] |
<[algo]> |
clearsilver is 0.10.1 |
| [18:57:22] |
<[algo]> |
is it ok ? |
| [18:57:34] |
<[algo]> |
not 0.10.3+ |
| [18:57:40] |
<coderanger> |
not the most recent, but should be okay |
| [18:57:45] |
<[algo]> |
cause of bugs in latest versions |
| [18:57:53] |
<coderanger> |
what version of sqlite? |
| [18:57:59] |
<[algo]> |
postgres |
| [18:58:02] |
<[algo]> |
8.latest |
| [18:58:17] |
<coderanger> |
try it with sqlite |
| [18:58:26] |
<[algo]> |
hm |
| [18:58:27] |
<coderanger> |
is the PG server on a different box? |
| [18:58:30] |
<[algo]> |
yes |
| [18:58:33] |
<[algo]> |
different box |
| [18:58:43] |
<coderanger> |
Have you checked network latency? |
| [18:59:10] |
<[algo]> |
I profiled trac |
| [18:59:14] |
<[algo]> |
and top functions were as posted |
| [18:59:23] |
<coderanger> |
That doesn't answer the question :P |
| [18:59:27] |
<[algo]> |
hm |
| [18:59:41] |
<[algo]> |
2 servers in same switch |
| [18:59:43] |
<[algo]> |
should be fine.. |
| [18:59:57] |
<coderanger> |
Try it with sqlite and see if things get better |
| [19:00:14] |
<[algo]> |
there is no data in postgres |
| [19:00:16] |
<[algo]> |
almost no data |
| [19:00:20] |
<[algo]> |
no much tickets |
| [19:00:22] |
<[algo]> |
and box is fast |
| [19:00:26] |
<coderanger> |
Thats not the issue |
| [19:00:32] |
<[algo]> |
I seriously doubt it is postgresql failure |
| [19:00:45] |
<[algo]> |
sites work with postgresql |
| [19:00:47] |
<[algo]> |
fast |
| [19:01:02] |
<[algo]> |
other services make use of postgresql and have no such issues |
| [19:01:07] |
<coderanger> |
if the app is sleeping in a read/write, it wouldn't show up in a profile anyway |
| [19:01:18] |
<coderanger> |
so the only way to be sure is to actually test it |
| [19:01:50] |
<coderanger> |
It could also be an issue in the pooler, or the python bindings |
| [19:01:51] |
<[algo]> |
I can make local postgresql |
| [19:01:55] |
<[algo]> |
hm hm |
| [19:02:02] |
<coderanger> |
(and still be PG related) |
| [19:02:14] |
<[algo]> |
well |
| [19:02:20] |
<[algo]> |
so small number of records |
| [19:02:24] |
<[algo]> |
and problems with database |
| [19:02:30] |
<coderanger> |
but trying with sqlite would rule all of that out (if it still happens) |
| [19:02:50] |
<coderanger> |
The latency of a query isn't really related to the number of records |
| [19:03:05] |
<coderanger> |
at least not at the low end of the scale |
| [19:03:08] |
<[algo]> |
well |
| [19:03:10] |
<[algo]> |
for timeline |
| [19:03:19] |
<[algo]> |
ok |
| [19:03:34] |
<[algo]> |
any tool to export ? |
| [19:03:43] |
<[algo]> |
postgresql trac into sqlite trac? |
| [19:03:58] |
<coderanger> |
Not that I know of, but you can try with just a new env |
| [19:04:24] |
<coderanger> |
if it is DB related I might not matter what data is in the Trac |
| [19:04:29] |
<coderanger> |
just how the DB access goes |
| [19:04:33] |
<[algo]> |
ok I'll try |
| [19:04:35] |
<[algo]> |
use sqlite |
| [19:04:37] |
<[algo]> |
and sync svn |
| [19:04:44] |
<[algo]> |
and check timeline generation speed |
| [19:04:57] |
<[algo]> |
fine test ? |
| [19:05:05] |
<coderanger> |
Its worth a shot |
| [19:05:36] |
<[algo]> |
going for it |
| [19:15:47] |
* |
Fastly has quit IRC |
| [19:43:02] |
* |
prologic has quit IRC |
| [19:44:26] |
* |
PingYeh has quit IRC |
| [19:45:07] |
<[algo]> |
well |
| [19:45:08] |
<[algo]> |
timeline |
| [19:45:12] |
<[algo]> |
takes 15 seconds to generate |
| [19:47:22] |
<prisoner> |
could you share with us the first and third lines from `top` when trac isn't running? |
| [20:00:17] |
<[algo]> |
trac.fcgi |
| [20:01:26] |
<[algo]> |
is 1st line |
| [20:02:12] |
<[algo]> |
98% |
| [20:02:47] |
<[algo]> |
Can I delete file attachments ? |
| [20:02:58] |
<prisoner> |
oh, I meant the header, the load average and cpu distribution lines |
| [20:03:29] |
<[algo]> |
1 1.820 1.820 9.910 9.910 /usr/lib/python2.4/HTMLParser.py:132(goahead) |
| [20:03:29] |
<[algo]> |
13321 1.760 0.000 4.410 0.000 /usr/lib/python2.4/HTMLParser.py:224(parse_starttag) |
| [20:03:48] |
<[algo]> |
top - 07:02:26 up 20 days, 5:00, 11 users, load average: 1.56, 1.20, 0.95 |
| [20:04:10] |
<[algo]> |
goahead and parse_starttag take together 14 seconds |
| [20:05:10] |
<coderanger> |
Thats all string parsing stuff |
| [20:05:20] |
<coderanger> |
How fast is the machine in question? |
| [20:05:24] |
<[algo]> |
2xXeon |
| [20:05:34] |
<coderanger> |
what speed though |
| [20:05:38] |
<[algo]> |
maybe some template caching is skipped ? |
| [20:05:51] |
<coderanger> |
thats not for templates |
| [20:06:02] |
<coderanger> |
its part of the form injector probably |
| [20:06:11] |
<[algo]> |
Intel(R) Xeon(TM) CPU 2.66GHz |
| [20:06:28] |
<[algo]> |
cache size : 512 KB |
| [20:06:29] |
<coderanger> |
that should be flying |
| [20:06:39] |
<[algo]> |
I await it so |
| [20:06:42] |
<coderanger> |
Is this in a vserver of any kind? |
| [20:06:43] |
<[algo]> |
but its crawling |
| [20:06:44] |
<[algo]> |
no no |
| [20:06:52] |
<[algo]> |
Gentoo Linux |
| [20:07:12] |
<[algo]> |
no VM |
| [20:07:27] |
<coderanger> |
my dev box is a dual core 1.6GHz mac mini it is very fast |
| [20:07:35] |
<[algo]> |
on timeline too ? |
| [20:07:39] |
<coderanger> |
on everything |
| [20:07:55] |
<[algo]> |
hm |
| [20:07:59] |
<prisoner> |
that load average is a big red flag, especially if it's just a front end box with no database server |
| [20:08:22] |
<coderanger> |
prisoner: That looks okay to me |
| [20:08:25] |
<[algo]> |
23817/2692 1.390 0.000 4.830 0.002 /usr/lib/python2.4/site-packages/trac/web/clearsilver.py:217(add_value) |
| [20:08:28] |
<prisoner> |
is there any idle time whatsoever? |
| [20:08:44] |
<[algo]> |
top - 07:07:23 up 20 days, 5:05, 11 users, load average: 0.57, 0.86, 0.87 |
| [20:08:44] |
<coderanger> |
prisoner: Having one process being queued is pretty normal |
| [20:09:26] |
<[algo]> |
that clearsilver add_value is called a lot |
| [20:09:35] |
<coderanger> |
Yes |
| [20:09:36] |
<[algo]> |
cumtime = 4 sec |
| [20:09:40] |
<coderanger> |
but its very fast |
| [20:09:45] |
<[algo]> |
cumulative time |
| [20:09:46] |
<[algo]> |
4 seconds |
| [20:10:00] |
<[algo]> |
HTMLParser is very slow too |
| [20:10:02] |
<[algo]> |
hm |
| [20:10:09] |
<[algo]> |
any ideas ? |
| [20:10:15] |
<coderanger> |
It really sounds like something is wrong with the setup |
| [20:10:16] |
<[algo]> |
that was timeline profile |
| [20:10:20] |
<coderanger> |
can you run the pystone tests? |
| [20:10:28] |
<[algo]> |
hm ? |
| [20:10:31] |
<[algo]> |
how ? |
| [20:12:18] |
<coderanger> |
hmm, I know the code is in test.pystone |
| [20:12:25] |
<coderanger> |
never tried running it myself though |
| [20:12:38] |
<[algo]> |
any magical word for me to type ? |
| [20:13:20] |
<coderanger> |
oone sec |
| [20:14:09] |
<coderanger> |
