Trac admin gateway timeout or internal server error

[ryandesign (Ryan Carsten Schmidt)]

In the admin page, I changed the project's description, and clicked Apply changes. After a minute or two, I got this:

Gateway Timeout

The gateway did not receive a timely response from the upstream server or application.

Apache/2.4.10 (Debian) Server at trac.macports.org Port 443

or sometimes this:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at webmaster@localhost to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Apache/2.4.10 (Debian) Server at trac.macports.org Port 443

The description did not get changed.

Note that the server administrator address in the httpd.conf should be changed to admin at macports dot org as well.

[neverpanic (Clemens Lang)]

I set the server admin address on all vhosts.

[raimue (Rainer Müller)]

The project description would be in trac.ini. This file can only be ​edited in git at the moment, since edits from the web interface will reorder options and strip comments. Sorry for the inconvenience.

[neverpanic (Clemens Lang)]

I've looked into the performance problems and found that we can drastically increase our processed requests per second by using more processes and fewer threads. I suspect contention on a resource that's shared between threads but separate for processes, either in Python itself, or in mod_wsgi.

For now, you should no longer receive timeouts. As @raimue already mentioned, the unwriteable state of trac.ini will stay, though, so this part of the ticket is wontfix.

[jmroot (Joshua Root)]

Replying to neverpanic:

I suspect contention on a resource that's shared between threads but separate for processes, either in Python itself, or in mod_wsgi.

That would probably just be the GIL if a lot of time is being spent computing in python code.

[neverpanic (Clemens Lang)]

Replying to jmroot:

That would probably just be the GIL if a lot of time is being spent computing in python code.

I see a single process using lots of CPU, and if I run ltrace on that process I see a number of calls into apr_*, which makes me think this is probably mod_wsgi code, not Python.