zope.session is sooooo slow and z3c.language.negotiator calls it for each message to translate if set to session.
I fixed that. Now z3c.language.negotiator can have a cache on the request. That brings up to 1/3 speedup on an average page. Just make sure you set cacheEnabled to True.

Recently activated a smallest windows rackspace cloud server (512M RAM, 20GB disk, win2003 server 64bit).
Performance is a lot better than expected. After login the server has still over 250M RAM free.
It's a 4x Quad-Core AMD Opteron(tm) Processor 2374 HE (2.2GHz, 7GHz IMC, 512kB L2, 6MB L3). CPU slices are capped, but still.
SiSoftware Sandra

Benchmark Results
Aggregate Arithmetic Performance : 26.28GOPS
Dhrystone ALU : 28.87GIPS
Whetstone iSSE3 : 23.7GFLOPS
Benchmark Results
Aggregate Memory Performance : 9.33GB/s
Integer Buff'd iSSE2 Memory Bandwidth : 9.25GB/s
Float Buff'd iSSE2 Memory Bandwidth : 9.4GB/s


They also have some serious disk subsystem:

Here is an enhanced version of a script found here: http://somanov.wordpress.com/2009/12/02/window-shortcuts-for-linux-desktops/

That version had the problem that it searched for the program_name in the complete wmctrl line not just in the class. That made it do bad switches. Like you had a folder open in Nautilus that had the name firefox in it, it considered Nautilus too as a Firefox candidate.


#!/usr/bin/env python
# -*- coding: utf-8 -*-
import os
import sys
import commands


program_name = sys.argv[1] # the program to be focused


# get all windows from wmcontrol
windows = sorted([x.strip() for x in commands.getoutput(
        """wmctrl -l -x""" ).split("\n") if x !=''])


wins = []
for win in windows:
    win = win.replace('  ', ' ')
    parts = win.split(' ', 5)
    d = dict(id=parts[0], klass=parts[2], title=parts[4])
    wins.append(d)


# filter candidates on klass
candidates = [w['id'] for w in wins
              if program_name in w['klass'].lower()]


if candidates:
    # at least one candidate found , we need to check if the active window is among the candidates (for cycling)


    # Get the id of the active window


    # Note: wmctrl currently does not support getting information about the active window.  In order to realize this
    #       we use xprop here. Unfortunately xprop gives us the window id of the active window in a different format:
    #       Window ids from wmctrl always begin with 0x followed by 8 digits (leading zeroes for padding). xprop
    #       does not do the padding and might give a window id starting with 0x followed by only 6 digits. The
    #       lines below get the id of the current window and make the id returned by xprop comaptible with
    #       the window ids returned by wmctrl.
    active_window_string = commands.getoutput(
        'xprop -root | grep "_NET_ACTIVE_WINDOW(WINDOW)"')
    active_window_string =  active_window_string[active_window_string.find("#")+4:].strip()
    active_window = "0x" + "0" * (8-len(active_window_string)) + active_window_string


    # the window to display. (one of the windows in candidates)
    next_window = None
    if active_window not in candidates:
        # if the active window is not among the candidate windows
        # ..just show the first candidate window
        next_window = candidates[0]
    else:
        # we are already showing one of the candidate windows
        # show the *next* candidate in the list (cycling)
        next_window = candidates[
            (candidates.index(active_window)+1) % len(candidates)]


    if next_window:
        # tell wmcontrol to display the next_window
        os.system('wmctrl -i -a "%s"' % (next_window,) )
else : # no windows open which fit the pattern of program_name
    os.system("%s &" % (program_name,)) # open new window

There was a nice debugzope script at the times when Zope 3 was packaged as a tarball. You could interactively dig into ZODB make your changes and commit.
Now at ZTK / egg / recipe / buildout times I was missing this. Therefore I created the recipe z3c.recipe.paster:debug.
(some code taken from grok ;-)

Add it to your buildout.cfg like this:

[debug]
recipe = z3c.recipe.paster:debug
app=app
where app is a z3c.recipe.paster:serve recipe.

Some more fixes:

• Sleep(100) on waiting for an external plugin to finish -- BAAH, Sleep(0) hogged the CPU
• never (try to) write back the .ini file -- well you might not have permission and I(!) am the one who writes the config
• PortNumber -- specify which port to bind to, well 4949 what else? but was a simple copy paste
• LogConnections -- ability to turn off that insane connect logging every 5 mins
• MasterAddress setting -- limit the IP address of the remote (master) server connecting. Right now to only 1 IP, but how many munin masters will you have?

Still need to adjust external plugins to be able to use existing munin-node plugins.
Goal would be to install (active)perl and run the existing munin plugin that's usually written in perl. Who wants to reimplement that again with e.g. python?

patch binary

Who said monitoring a windows server is impossible with munin?

There is munin-nodewin32 on sourceforge, but it was a bit crippled with external plugins.
The problem with monitoring memory usage was fixed in svn but not yet compiled.
Here is a patch and binary that fixes that.
After that it's easy to write plugins (in python) to monitor what you want.

There's a script called debugzope, that sounds like a debugger. But in real life you can examine the whole ZODB with it. You can even make changes to the ZODB or ZEO. All in all quite handy if you have to correct a few objects in the database, also on a live system.

$ bin/debugzope

Now the variable root becomes your DB's root. All configuration should be taken from the live system in which context it was started.

>>> root
zope.app.folder.folder.Folder object at 0x01C31C70

You can do any changes (and anything) using the usual python commands. The whole Zope infrastructure is in place.

Don't forget to commit when you are ready:

>>> import transaction
>>> transaction.commit()

Otherwise all changes will be reverted on exit!

debugzope(.bat) is usually available if you use the old zopeskel style deployment. The next task is to figure out how to do this with a buildout based deployment.