[Trac] Re: I need a trac consultant
Thanks for the update. Based on another email, I have a quick question. Are you using mod_deflate on Apache? I have also been doing some load testing in relation to issue #7490. My results, assumptions, testing environment, and test scripts can be found at http://trac.edgewall.org/wiki/Performance. I would be interested in seeing the results of other people duplicating these test as it may help in reproducing problems like the one you have been working on. I have also been doing some profiling of the Trac-0.11-stable code base and have found no surprises, but I still do have a few theories to test with regards to I/O, available memory, and performance; however until I can construct some tests to disprove these theories, I don't have anything definite to share. For those following any of my previous threads on this, I have switched the load testing tool to Apache JMeter so that others can more easily perform similar testing on their systems (as opposed to the proprietary tool that I was using previously). Please let us know if you find anything else. Lance Chris Peterson wrote: OK, so let me update briefly on some changes I have done. The only bad part here is, none of the changes *singly* have made a large difference in performance, but all together it seems to be running much better. I set Apache to have 100 process threads rather than 250 I disabled DEP on Windows (which was enabled by default) I disabled the source browsing from all hosted trac environments I disabled all authentication to the /chrome folder, my Location directive for the chrome folder looks as such: Location /chrome Satisfy Any Allow from all ExpiresActive On ExpiresDefault access plus 30 days /Location I ran some IO tests on the S3 drive vs the host OS drive, and while the S3 drive did show some high variances on speed, it also had peaks of very quick performance (as I would expect from a highly shared resource), so I do not believe that is my sole IO issue. Performance seems much better overall now, and normal page requests are no longer peaking the CPU quite so badly, but the wiki page still consumes 100% CPU for approx 1 - 2 seconds, then drops back down. I think (at this late time at night on the weekend) that performance is acceptable now, but I will need to get it under load before I know for certain. Each one of these changes have seemed to cause an improvement, and all together it seems pretty happy now =) Thanks to everyone for all your idea's. I believe my next steps here will be to update to the 1.6.2 release of SVN, and I believe I will also update the Sqlite databases to either MySQL or PostgreSQL and see if I can find some additional performance gains that way. If anyone has a recommendation on which way to go with the Trac database for performance and ease of upgrading 50 environments or so, please feel free to chime in! Hope everyone is having a great evening, Chris Peterson Alagad, Inc. On 6/5/09 12:57 PM, Christian Boos cb...@neuf.fr wrote: Chris Peterson wrote: I work with Doug on this issue, and I wanted to provide some additional details about our configuration and what I am seeing. The server is an Amazon EC2 small instance, running on a dual core Opteron 2.6 ghz w/ 1.66 gig of ram The Trac install lives in the default c:\python25 folder, and the trac / svn data lives on an S3 drive. Ah well, you're the author of comment:57 - didn't you indicate there that changing the log_level was helping? Also, did you test on some similar local machine as well? We have 49 trac environments running here, 4 of which have their own v- host configured, the rest are for internal use and share a root url. All of these environments also have SVN setup. The majority of the shared instances have a common configuration base trac.ini file, with individual files for environment specific configurations. I started out with the 0.11 install of Trac, and have since upgraded to the 0.12dev-r8263 release from SVN (using easy_install and pointing to the SVN repo location), to try and address our performance issues. Under 'About Trac', here is my current config: Trac: 0.12dev-r8263 Python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] setuptools: 0.6c9 SQLite: 3.5.2 pysqlite: 2.4.0 Genshi: 0.6dev-r1052 Babel: - mod_python: 3.3.1 Pygments: 1.0 Subversion: 1.5.4 (r33841) jQuery: 1.1.3.1 Side note, should be jQuery: 1.3.2, no? (that's what is checked in into trunk, AFAICT). I have Apache connecting using mod_python, but this slow performance and 100% CPU peak usage persists even if I load a single environment using tracd and shut-down the apache instance. Ok, that's very interesting: you're able to reproduce the perfomance issue with tracd serving a single environment. Let's forget
[Trac] Re: Performance
ms - I need to go through and clean up the table (alignment and labels) as this is the raw information straight from the tool. Thanks for pointing that out though. Lance Shane Caraveo wrote: I have also been doing some load testing in relation to issue #7490. My results, assumptions, testing environment, and test scripts can be found at http://trac.edgewall.org/wiki/Performance. I would be interested in seeing the results of other people duplicating these test as it may help in reproducing problems like the one you have been working on. Hi Lance, What are the numbers in the results on that page? ms? req/s? Regards, Shane --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Performance
Yeah, that was a good thought... Lance Shane Caraveo wrote: Think I was happier with donuts per cup of coffee ;) On 6/16/09 12:45 PM, Lance Hendrix wrote: ms - I need to go through and clean up the table (alignment and labels) as this is the raw information straight from the tool. Thanks for pointing that out though. Lance Shane Caraveo wrote: I have also been doing some load testing in relation to issue #7490. My results, assumptions, testing environment, and test scripts can be found at http://trac.edgewall.org/wiki/Performance. I would be interested in seeing the results of other people duplicating these test as it may help in reproducing problems like the one you have been working on. Hi Lance, What are the numbers in the results on that page? ms? req/s? Regards, Shane --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac wiki markup vs ReST
Interesting thread and also interesting to see how much everyone likes Trac wiki syntax. I will add my $0.02 US and also take as IMHO: While I agree that simple text and things like TODO and instruction related documentation are relatively easy to do in markdown, I have (and it may be due to my lack of experience with) had difficulties with almost all mark down languages when it comes to technical documentation. If it is simply a question of Trac wiki or ReST, then I don't really have a strong preference, but I would lean toward Trac wiki (as much as I like what I have reviewed and researched with regard to Rest) as then all my work with/around Trac would use a consistent format; however... At the risk of (a strict interpretation of the thread) taking us off topic, I would also suggest that if we plan to leverage version controlled documentation for various releases that some of the limitations (tables being a big one) of markdown will become more significant and for that reason I would suggest at least considering another richer format. As mentioned previously, I have settled on just such a format for the bulk of the content I develop and thankfully, the other OSS project I am working on also supports the same format for their documentation. The advantages of these are their (obviously) richer format and (at least based on my limited knowledge of Trac wiki and ReST) ability to be easily transformed to other format and supported by a significant number of tools. The is obviously more complex, but there are tools available to help assist with the development of the documentation (which is another big advantage of a standard mark up)... Lance Roger Oberholtzer wrote: On Mon, 2009-06-08 at 14:36 +0200, Eirik Schwenke wrote: Christian further mentions: (Trac has) Much improved table markup (the reST table markup is unbearable). This would be: http://trac.edgewall.org/wiki/WikiFormatting#Tables vs: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#simple-tables http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#grid-tables I do miss the ability to span columns and rows. Especially columns. If Trac had this, I would not need any change to the table syntax. I confess, I use the WYSIWYG trac plugin to manipulate tables. I get some pretty hefty ones, and adding a column can be a real PITA. Even if I cut/paste from my favorite vi. -- Roger Oberholtzer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: ldap authentication and anonymous query
I assume you are speaking of OpenLDAP (2.2 and 2.4)? Lance Dimitri Maziuk wrote: On Sunday 07 June 2009 17:43:57 Sergio Charpinel Jr. wrote: Yes, but it works as one. Try and see your ldap log. It is in the LdapAuthStore module for AccountManager. But it was not working in my ldap 2.4 , just in 2.2. So I changed and did a real bind. Easy fix (assuming your ldap server is firewalled off etc): change access to * from by * none to by * read in your slapd.conf (or do what you did and use a non-anonymous bind). Yes, by * none worked in 2.2 with by anonymouth auth access to password and and by * read access to uid etc. They've changed something in 2.4 and forgot to tell us what it is. Dima --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: I need a trac consultant
I did some load testing yesterday with almost this same configuration and I was able to achieve some pretty good results and did not see any issues. I am not yet prepared to publish the results, but one interesting difference was that you appear to be running this on windows, whereas I was running on Linux. Just as an FYI, I was able to get just over 18 requests/second with about an average of 1s for page load with tracd and was able to get just over 34 requests/second with mod_python with sub second page load times on an AMD dual core 2mhz. The testing results page I am putting together has much more detail on the hardware and software configuration I was using as I know these numbers probably don't mean too much without that detail, but thought you might find them re-assuring (that it is possible). I will replicate the test on Windows and see if I can reproduce this issue. Once I have finished polishing the results and working with the devs to ensure they are reasonable, I will happily publish the details of this testing. The reason for my doing this is that I am attempting to assist with ticket #7490 (http://trac.edgewall.org/ticket/7490) but I have not yet been able to reproduce the issue. However, I have not had as much detail (as yet) as you have provided, so this information is much appreciated. Chris Peterson wrote: I work with Doug on this issue, and I wanted to provide some additional details about our configuration and what I am seeing. The server is an Amazon EC2 small instance, running on a dual core Opteron 2.6 ghz w/ 1.66 gig of ram The Trac install lives in the default c:\python25 folder, and the trac / svn data lives on an S3 drive. We have 49 trac environments running here, 4 of which have their own v- host configured, the rest are for internal use and share a root url. All of these environments also have SVN setup. The majority of the shared instances have a common configuration base trac.ini file, with individual files for environment specific configurations. I started out with the 0.11 install of Trac, and have since upgraded to the 0.12dev-r8263 release from SVN (using easy_install and pointing to the SVN repo location), to try and address our performance issues. Under 'About Trac', here is my current config: Trac: 0.12dev-r8263 Python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] setuptools: 0.6c9 SQLite: 3.5.2 pysqlite: 2.4.0 Genshi: 0.6dev-r1052 Babel:- mod_python: 3.3.1 Pygments: 1.0 Subversion: 1.5.4 (r33841) jQuery: 1.1.3.1 I have Apache connecting using mod_python, but this slow performance and 100% CPU peak usage persists even if I load a single environment using tracd and shut-down the apache instance. I have gone through the site-packages and, one by one, removed each plugin from the folder and re-started the instance, and I still saw the performance issues (I was trying to isolate the issue to a single plugin, without luck). I applied the patch as suggested in http://trac.edgewall.org/ticket/7785#comment:13 and have seen no improvement. I also have logging currently disabled completely in the hopes of improving performance, still without luck. I did a directory output from my site-packages folder, if it will provide better detail as to plugins I have installed, that you can view here: http://pastebin.com/fea11695 The worst performance seems to be on the wiki pages, but viewing tickets spins the CPU up quite high as well. At one point I attempted to implement the Psyco package (http://psyco.sourceforge.net/) to improve performance, but all plugins have been updated without it again as I saw no performance gains from using it (the package is still in my site-packages, but the code is not in use) At this point I am (sadly) thinking that I may need to re-configure a new server with a clean / new install of python and trac and see how it runs, I really do not know what else to investigate to resolve this problem. Any idea's, as wild as they may be, would be greatly appreciated! Chris Peterson On Jun 4, 6:31 pm, Christian Boos cb...@neuf.fr wrote: Doug Hughes wrote: Hi, We have a new install of Trac running on Windows with Apache. (Generally, the same setup as our old Trac instance.) Unfortunately, performance is terrible. Requests spike the box to 99% cpu and httpd is taking 500mb. We're out of ideas here and I'd like to have someone come in, take a look at our config, tell us what we did wrong, and then make it work. This sounds a lot like ticket #7490. Please give us more details about your installation (http://trac.edgewall.org/wiki/NewTicketGuidelines#HowtoProceed). You may try 2 different things: - reduce the log_level if it's set to DEBUG, down to ERROR - apply the patch on #7785
Re: Trac wiki markup vs ReST [Was: Re: [Trac] Re: Trac Recipies]
As a (potential) contributor, I would say that I only have two requirements:
1. Write content once (render many or as needed)
2. Maintain as few copies as possible (preferable only one master copy)
Otherwise, I could care less (mostly) where or how (wiki or Rst). If
you asked me, out of context of Trac, I would suggest DocBook (it's what
I decided on when evaluating what to write content for my personal
web-site with), but I don't think it makes sense in the context of
Trac. My only fear is of having to maintain or create the documentation
in both Rst and (Trac) wiki. Disclaimer - I *mostly* work with US
character sets and keyboard layouts, so I don't have experience with
issues surrounding multi-lingual or non-en-US layouts.
My $0.02 US
Lance
Eirik Schwenke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Boos skrev 03. juni 2009 23:37:
yoheeb wrote:
Although, I must ask: Why is the Trac Documentation in .rst format,
instead of trac wiki markup,
It's not. Some people thought it would be a good idea to restart the
documentation from scratch in .rst, targeting the use of Sphinx, but
that effort has stagnated and others (me being in the front line) are
quite skeptical to the very idea of using anything else than Trac's own
wiki markup for the purpose of writing the Trac admin and user
documentation. The Trac developer guide is another story and for that
purpose, Sphinx seems to be perfectly suited.
OR, why doesn't trac drop it's wiki
format for straight .rst format, instead of having to use a markup
block? yes, maybe some of the docs existed before the tool...etc.
Just a thought.
Because the barrier to entry is much lower for the Trac wiki markup, the
likeliness is really low that a Trac user will learn yet another markup
language (and .rst is not the most intuitive one) just for contributing
a bit of her knowledge to the Trac knowledge base.
Why not use restructured text ? It supports direct generation of
latex/pdf/s5 slides, has a well defined design for extension, and IMNHO
is quite readable.
I would contend that those not able to read rst would be better served
by a WYSIWYG editor anyway ?
I really don't mean this in a negative way, but do you think:
http://trac.edgewall.org/wiki/WikiFormatting
is significantly easier on the eye, or more intuitive than:
http://docutils.sourceforge.net/docs/user/rst/quickref.html ?
(See also: [RstQuickRef]_).
If so, I would appreciate you taking the time to elaborate. Perhaps
because Trac's markup is closer to other wikis ? I realize that we now
have a lot of legacy users (me included:) -- so a change is ill
advised without good reason.
Personally I find that '''bold''' and ''italic'' is a) wrong (not what
you *mean* but what you see, and b) rather visually meaningless in the
text editor (contrast: *emphasis* **strong emphasis** with ''emphasis''
(or is it a quotation) and '''strong emphasis''' (looks a bit like a
block-quote?)).
RST has less special characters in the markup, which is great for those
of us not using a US layout --
ctrl-altgr/meta-7,ctrl-altgr/meta-7,ctrl-altgr/meta-7 for a
codeblock/monospace (or shift-next_to_backspace-space for backtick)
isnt't all that easy -- and reading the source document, a simple:
.. code-block:: python
:linenos:
#Some python code -- but just a comment for this example
#it will be printed with line numbers (:linenos: directive).
The above code is a block, by virtue of it's indentation. The markup
arguably works in a plain-text print-out.
{{{
#!python
#This also works. Explicit termination of blocks, rather than
#python-like indentation can be a benefit -- but it doesn't look very
#pretty -- or intutitive -- again IMNHO
}}}
I know these are small details -- but I'm trying (actually, not
rhetorically) to see how the trac wiki markup can be considered
better, even for use in the wiki.
The syntax styles are not radically different -- but I feel that Rst is
better suited to evolving texts (full pages, rather than short
snippets). It's easier to work with the source document, and more
usable in a version controlled environment.
RST has some serious limitations, eg: limited autonumbering of lists,
underscore for linking (not very wiki-like). Rst also has rather limited
support for mulitple levels of headings -- while I think the 6 headings
for html is a bit overkill, Rsts two-and-a-half (=/- look different
enough and make sense -- but the tilde (~) is a poor choice for third
level down IMNHO).
Rst also uses the backtick, wich isn't a very good idea -- the number of
non-printing characters that make sense in a multilingual and
multiscript (eg: Japanese and Chinese kanji) environment is
very limited. Dash -, underscore _, equal =, colon/semicolon as
well as single and double quotes is about the limit.
Due to the popularity of email/it's use in
[Trac] Re: Trac/SVN on Windows Install Problem
Sounds like it might be a permissions issue with Apache and the SVN directory. I assume you are running as (or in) the administrator (group) when you are using trac-admin, so when you do command line stuff, it is accessing SVN with credentials as an administrator; however, I also assume that the account that Apache is running under is not a member of the administrators group, so this sounds like a typical permissions problem. Check the account that Apache is running under and ensure that the directory your SVN repository is located in has the proper permissions (and subdirectories, so your subdirectories should inherit permissions from the parent) for the account that Apache is running under. This would be my first guess, but let me know if you have already checked this or if this is not the issue. Lance raiderdav wrote: Configuration: Trac 0.11.4 SVN 1.5.6 (r36142) Python 2.5.4 Apache 2.2.11 Windows Small Business Server 2008 I'm installing Trac for the first time on this server, and am having issues connecting to the SVN repository. I believe I have the Trac environment established successfully, and can connect via Apache using the mod_wsgi approach with the repository_dir cleared. With my Trac.ini file set with the following I can view the generic Welcome to Trac page and local documentation: repository_dir = repository_type = svn When I change it to repository_dir = c:\svn\ltm the Trac URL is no longer accessible and I get a Connection Interrupted. The connection to the server was reset while the page was loading. in the browser. I turned on debug logging to file, and the last line of the log reads: 2009-06-02 14:25:03,322 Trac[main] DEBUG: Dispatching Request GET u'' With the repository_dir set with the correct path, I can run trac- admin resync and the repository history counts through all 292 revisions successfully. This leads me to believe that the connection to SVN is established properly, but I still can't view anything with the repository path included. Any ideas on what to check or test next? Thanks - Dave --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac Recipies
In line with your note, perhaps you could suggest a few items (or a few topics) that you especially feel would be important/critical/useful to develop (what were you unable to find documentation about). IMHO one of the biggest issues facing the adoption of OSS is the lack of documentation and as a result one of my major objectives to support the OSS effort is to attempt to provide or at least assist with the development of (I am capable of at generating content quickly, I'll let someone else be the judge of it's usefulness) documentation; however, in order to be most useful, I think the effort should be driven by the community (as to what to develop). In short, while you could develop the documentation yourself (as has been suggested), there is also the option of assisting or collaborating with someone (me?) to help improve the documentation. Anyone else with any documentation requests would also be welcome. (I know, be careful what you wish for...) Lance Dan Winslow wrote: So do I. Track hacks is a OK place to get plugins from, but not information on how to do things. In general there is a crippling lack of information all across the web about TRAC. I have spent two weeks trying to understand various aspects of TRAC, and I am just now starting to get a vague idea. I am not a python programmer, nor do I have any wish to become one. All of the documentation I can find about a specific subject is usually only a few terse sentences, maybe a **very** short example, and then they all trail off with ‘ .. and of course, you can always write a plugin to do anything more.’. I don’t want to write plug-ins. I don’t want to have to read through bunch of alien-looking code to try and figure out what it means. I’m not faulting the developers in particular, they’ve done a fine job and it’s a huge amount of work to maintain decent docs. I was so frustrated that I tried to get management to let me write my own system, but they declined. I think a collection point for trac recipies would be a greta idea. *From:* trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] *On Behalf Of *Ariel Balter *Sent:* Wednesday, June 03, 2009 12:59 PM *To:* trac-users@googlegroups.com *Subject:* [Trac] Re: Trac Recipies I disagree. Noah Kantrowitz wrote: Trac-hacks is that site. --Noah -Original Message- From: trac-users@googlegroups.com mailto:trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of abalter Sent: Wednesday, June 03, 2009 10:52 AM To: Trac Users Subject: [Trac] Trac Recipies I would like to help put together a site of recipes for using Trac. There is a ton of great information in this email list and forums and out there on the web. I think it would be great to take a sort of best of of the actual solutions and organize them into a set of recipes such as You want to do XXX...Do this:. Not surprisingly, I thing the best way to build this recipe book is with a Trac site. The first thing I would need would be a place to host it. Perhaps the folks that run Trac-hacks would be willing to give me some space. Or, perhaps edgewall.com. I'm open to suggestions. I'd love to hear feedback on this idea. Thanks, Ariel -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Ariel I Balter, Ph.D. Postdoc Biological Monitoring/Modeling Fundamental and Computational Sciences Directorate Pacific Northwest National Laboratory Mail: PO Box 999, MS P7-58,Richland, WA 99352 Shipping: 790 6th Street, MS P7-58, Richland, WA 99354 Tel: 509-376-7605 Cell: 509-713-0087 ariel.bal...@pnl.gov mailto:ariel.bal...@pnl.gov www.arielbalter.com http://www.arielbalter.com www.pnl.gov http://www.pnl.gov --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac Recipies
BTW, I didn't mean to hijack your thread with my previous note. I think your ideas is great. I'll leave the discussions of where to others, but let me know if you need any assistance with developing the documentation or if you just want someone to review it. Lance abalter wrote: I would like to help put together a site of recipes for using Trac. There is a ton of great information in this email list and forums and out there on the web. I think it would be great to take a sort of best of of the actual solutions and organize them into a set of recipes such as You want to do XXX...Do this:. Not surprisingly, I thing the best way to build this recipe book is with a Trac site. The first thing I would need would be a place to host it. Perhaps the folks that run Trac-hacks would be willing to give me some space. Or, perhaps edgewall.com. I'm open to suggestions. I'd love to hear feedback on this idea. Thanks, Ariel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
