DNA-Analysen: Bayern startet Bundesratsinitiative - wer sonst wenn nicht die Bayern? Aktuelle Vorkommnisse werden als willkommener Anlass gesehen um schnell irgendwelche Änderungen durchzuprügeln. Egal das durch diese Änderung weitaus mehr als mit Fingerabdrücken möglich wird - und das viel mehr Missbrauchsmöglichkeiten vorhanden sind (z.B. Gen-Analyse zur Bewertung von Tauglichkeiten).
Auch das Urteil des Bundesverfassungsgerichtes das explizit DNA Analysen auf besonders schwere Verbrechen eingeschränkt hat wird dabei ignoriert. Wen schert auch das Bundesverfassungsgericht, wenn man mit Populismus so schön für Stimmung sorgen kann ...
Grafedia ist sowas wie Links für die Hardware da draussen. Ein Wort als eMail-Adresse unter einer Domain benutzt und man erhält als Antwort ein File. Das Konzept ist also simpel - interessant wird es dadurch, das man Handys einsetzt um die Mail zu schicken - und das Ergebnis auch aufs Handy zurückbekommt. Und das man die Wörter irgendwo draussen an Wände und ähnliches packen kann. Irgendwie verrückt, irgendwie schön. (Gefunden beim Spreeblick)
LynuxWorks Introduces First User-Mode Linux Software for Apple PowerPC G5 Based on the Linux 2.6 Kernel - damit kann man jetzt auch auf PPC-Maschinen logisch getrennte virtuelle Umgebungen unter Linux aufbauen.
MathWorld News: The Mathematics of Tsunamis - interessante (wie ich finde) Erläuterung der Wellenentwicklung von Tsunamis. Gefunden im zeitwissen:log.
5 Minuten gegrübelt welches Gerät gerade einen Alarm abgegeben hat und woran zum Geier mich das erinnern sollte. Nach dem Check von mehreren Geräten und Programmen gemerkt das es ein eigentlich schon längst gelöschter Alarm im (nicht gesyncten, daher nicht aktuellen) PDA war. Mangelnde Erkennungsfähigkeit von Alarmsignalen durch Alarmtondiversitätsüberlastung ...
Brian Mastbrook beschreibt sehr schön wie Quicksilver das beste aus den Welten der tastaturgesteuerten Interfaces und der grafischen Interfaces verbindet. Leider läuft QuickSilver erst ab 10.3, weshalb ich immer noch mit LaunchPad festhänge - das allerdings in den neuesten Versionen (bis auf den wirklich extrem lahmen Start) schon ganz gut mithalten kann.
Allgemein finde ich diese sich langsam entwickelnde Idee der Kombination von grafischen und tastaturgesteuerten Interfaces sehr angenehm. Grafische Oberflächen sind zwar gut in der Präsentation von komplexeren Strukturen (eine Verzeichnisstruktur erschliesst sich mir grafisch schneller als von der Shell), aber oftmals doch recht umständlich zu bedienen. Tools wie QuickSilver und LaunchPad helfen da ungemein. Vermutlich würde auch Apples Universal Key Access mir helfen - hätte ich 10.3 ...
Save Think Secret's Nicholas Ciarelli Petition sollte man als Apple-User sich ĂĽberlegen zu unterschreiben. Diese Klagerei von Apple jedenfalls ist weder positiv noch sinnvoll - schliesslich lebt die Apple-Welt auch unter anderem von ihren GerĂĽchten. Gefunden beim Spreeblick.
The Temboz RSS aggregator ist ein sehr nett gemachter Aggregator in Python. Er benutzt den Ultraliberal Feedparser für das Parsing und kann OPML importieren. Die Oberfläche finde ich schick gestaltet und die Administration ist recht simpel. Und er hat ein paar nette Features wie das zweispaltige Layout und die recht einfache integrierte Filtermöglichkeit sowie recht brauchbare Feedlistensortierungen. Ich spiel mit dem gerade mal ein bischen herum - auch wenn das warscheinlich meine Motivation einen eigenen Aggregator zu schreiben reduzieren wird
Working with Automator beschreibt wie das neue Automationswerkzeug von Mac OS X 10.4 arbeitet. Macht neugierig ... (Gefunden beim Schockwellenreiter)
Der Schockwellenreiter hat Probleme mit seinem Zope-Server. Da ich nun schon seit einigen Jahren professionell (in der Firma) Zope-Hosting mache und dabei auch ein paar ziemlich heftige Portale laufen habe (zwischen 2000 und 3000 Hits pro Minute sind da nicht selten - allerdings verteilt auf viele Systeme), hier mal ein paar Tipps von mir zur Skalierung von Zope.
- Der wichtigste Schritt, den ich jedem empfehlen würde, ist entschlacken. Werft aus dem Zope all das raus was nicht rein muss - was statisch erstellt werden kann, was sich nur selten ändert, wo kein Content-Management nötig ist: raus damit. Packt es in normale Apache-Verzeichnisse. Nehmt Apaches mod_rewrite und sorgt dafür das die alten Adressen weiter funktionieren, aber aus dem Apache kommen. Das betrifft vor allem all die kleinen Scheisserlein wie Layoutgrafiken und so - die brauchen nicht aus dem Zope zu kommen, die werden besser aus dem Apache geliefert.
- Benutzt das Zope-Caching, wenn irgend möglich. Irgend möglich heisst: genug Speicher auf dem Server, damit auch sich fettfressende Prozesse mal etwas Luft haben. Generell führt das Zope-eigene Caching dazu, das Prozesse immer fetter werden - das Aufräumen im eigenen Cache ist recht unbrauchbar. Also setzt eine Prozessüberwachung ein, die einen Zope-Prozess abschiesst und neu startet wenn er zu viel Speicher braucht. Ja, das ist wirklich sinnvoll und notwendig.
- Gute Cachingmöglichkeiten gibt es im Zope zwei: den RAMCacheManager und den HTTPCacheManager. Ersterer speichert Ergebnisse von Zope-Objekten im Hauptspeicher und kann daher einzelne Seitenkomponenten cachen - packt das da rein, was komplex zu ermitteln ist.Der zweite (HTTPCache) arbeitet mit einem Squid zusammen. Packt einen Squid als HTTP Accelerator vor euren Zope und konfiguriert den HTTP Cache Manager entsprechend, so das Zope die passenden Expire-Header erzeugt. Dann wird ein Grossteil eures Traffics aus dem Squid betrieben. Der ist schneller als euer Zope. Alternativ zum Squid kann man auch einen Apache als HTTP Accelerator mit lokalem Cache konfigurieren - ideal für die, die keinen Squid installieren können oder wollen, aber durchaus Möglichkeiten zur weitergehenden Konfiguration eines Apache haben.
- Grosse Zope-Objekte (und das meine ich wirklich im Sinne von KB) machen Zope tot. Beim Caching zerfetzen sie einem die schönste Cache-Strategie und Zope selber wird arschlahm wenn die Objekte zu gross werden. Der Grund liegt in der Zope-Architektur: alle Objekte werden erst mühsam in mehreren Schichten durch mehrere Softwarelayer zusammengedengelt. Im Speicher - und belegen daher im Speicher auch entsprechend Platz. Raus mit den komplexen Objekten mit riesigen KB-Zahlen. Macht sie kleiner. Erstellt sie statisch per Cronjob. Liefert sie aus dem Apache aus - es gibt nix blöderes als seine grossen PDFs alle im Zope in der ZODB abzulegen, oder gar dynamisch dort zu generieren.
- Installiert ZEO. Das Teil rockt. Im Prinzip ist es nur die ZODB mit einem primitiven Serverprotokoll. Wichtig daran: euer Zope kann auf mehrere Prozessgruppen aufgeteilt werden. Das wollt ihr wenn ihr per Prozessüberwachung einen amoklaufenden Zopeprozess abschiessen wollt, aber das Portal von aussen möglichst unbeschädigt aussehen soll - in dem Fall packt ihr auf den Apache einfach mod_backhand drauf, oder eine andere Balancer-Technik zwischen Apache und Zope. Zusätzlich macht der ZEO auch das Packen der ZODB (sollte täglich laufen) einfacher, da der Pack im Hintergrund auf dem ZEO läuft und die Zope-Server selber nicht gross beeinträchtigt werden.
- Wenn ihr habt, nehmt einen SMP-Server. Oder kauft euch einen. Wirklich - das bringt ne Menge. Voraussetzung ist allerdings die oben angesprochene Technik mit den mehreren Prozessgruppen - Python hat ein globales Interpreterlock, welches dazu führt das auch auf einer Mehrprozessor-Maschine eh nie mehr als ein Python-Thread gleichzeitig läuft. Von daher wollt ihr mehrere Prozessgruppen.
- Performance gewinnt man auch durch Ausschaltung von Schichten. Leider ist das oft nur mit Softwareänderungen realisierbar, daher eher für Selberstricker interessant. Packt komplexe Abläufe raus aus dem Zope-Server und packt sie in Zope Products. Zope Products laufen native ohne Beschränkungen im Python Interpreter. Zope Python Scripte und DTML Dokumente werden hingegen durch viele Layer geschleppt die dafür sorgen das ihr euch an die Zugriffsrechte von Zope haltet, nichts böses tut und auch sonst ganz lieb seid. Und sorgen dafür das ihr langsamer werdet. Products lohnen sich - kosten aber Arbeit und sind entgegen der anderen mehr technischen Tipps nicht immer umsetzbar.
- Zusätzlich hat es sich bewährt nicht zu viel Daten in die ZODB zu packen, vor allem nichts was diese erweitert - die ZODB wird nämlich nur grösser, kleiner wird sie nur beim Packen. Nach einiger Zeit hat man dann locker eine ZODB im GB-Bereich und braucht sich über langsame Serverstarts nicht wundern ...
- Wenn komplexere Abläufe im System vorkommen kann es Sinn machen die ganz auszulagern. Bei mir kommt dann immer das |TooFPy| zum Einsatz. Einfach die ganzen komplexeren Sachen in ein Tool umwandeln und dort reinhängen - der Code läuft ungebremst schnell ab. Vom Zope dann einfach mit einem SOAP Client oder XMLRPC Client auf den Toolserver zugreifen und die Funktionen dort ausführen. Ja, die mehrfache XML Wandlung ist tatsächlich weniger kritisch als der Ablauf von komplexerem Code im Zope - vor allem wenn dieser Code einiges an Laufzeit beansprucht. Zope blockiert dann nämlich einen seiner Listener - die Anzahl ist statisch. Und einfach hochdrücken bringt nix - dank des globalen Interpreterlocks würden dann nur mehr Prozesse aufeinander warten, das dieses Lock freigegeben ist (z.B. bei jeder C-Erweiterung die zum Einsatz kommt). Für die XMLRPC Kommunikation gibt es eine gute und schnelle C-Implementierung die in Python integriert werden kann, damit ist das XML-Overhead-Problem irrelevant.
- Wenn ihr PostgreSQL als Datenbank benutzt: nehmt PsycoPG als Datenbanktreiber. Das Session-Pooling bringt Zope erst richtig auf Touren. Generell solltet ihr schauen ob der entsprechende Datenbanktreiber irgendeine Form von Session Pooling unterstützt - notfalls über einen externen SQL Proxy. Denn sonst hängt in Zope bei SQL-Queries unter Umständen das ganze System, weil eine fette Query auf das Ergebnis wartet. Da ist schon mancher drauf reingefallen und hat lernen müssen das 16 Zope-Threads nicht gleichbedeutend mit 16 parallel bearbeiteten Zope-Zugriffen bedeuten muss, wenn SQL-Datenbanken im Spiel sind.
Es gibt natürlich noch eine ganze Menge mehr Sachen die man machen kann, aber die obigen sind weitestgehend aus dem Stand zu bewältigen und hauptsächlich davon abhängig das ihr genug Speicher im Server habt (und evtl. eine Mehrprozessormaschine - geht aber auch ohne). Wichtig ist der Speicher - je mehr desto besser. Wenn geht, steckt halt noch mehr Speicher rein. Man kann nicht zu viel Speicher haben ...
Was machen wenn das alles auch noch nicht reicht (ja, ich hatte das schon - manchmal hilft nur die ganz grobe Axt). Nun, in dem Fall gibt es Abwandungen der obigen Techniken. Meine Lieblingstechnik in dem Bereich ist aktives Caching. Damit meine ich, das im Zope an einer Stelle hinterlegt wird welche Dokumente aktiv gecached werden sollen. Dazu gehört dann auf der Kiste ein Script, das die Seiten vom Zope abruft und in ein Verzeichnis packt. Per Apache Rewrite Rules wird dann dafür gesorgt das von aussen die statischen Inhalte ausgeliefert wird. Im Prinzip sorgt man also dafür das die Seiten die am häufigsten besucht werden und die für diese Technik geeignet sind (also z.B. keine Personalisierungsdaten enthalten) einfach eine statische Seite rausgeht, egal was sonst passiert - die normalen Cachetechniken gehen da einfach nicht brutal genug vor, da geht noch zu viel Traffic durch auf den Server.
Ein weiterer Schritt ist natĂĽrlich der Einsatz weiterer Maschinen - einfach weitere Kisten daneben stellen und mit der ZEO-Technik miteinander verbinden.
Zope ist eine fantastische Software - gerade die hohe Integration von Entwicklungsumgebung, CMS und Server ist oft ungemein praktisch und die leichte Integrierbarkeit in externe Datenquellen ist ebenfalls sehr nett. Aber Zope ist ein Ressourcenschwein, das muss man so einfach mal sagen.
Debian hat ein wunderschönes Paketsystem. Und es hat eine ganze Reihe von sehr brauchbaren Werkzeugen um Backports einfacher zu machen - zum Beispiel in dem man mit debootstrap ein chroot-Environment zusammenstellt in dem man gefahrlos die Pakete zusammentragen kann die man für den Build braucht und dann ein entsprechendes Paket erstellt. Ich habe das ganze schon mehrfach benutzt, es ist wirklich klasse.
Allerdings kann einen das auch manchmal in den Wahnsinn treiben. Ich wollte die neuste SQLite aus der Debian Testing installieren. Dazu brauche ich erstmal die nötigen Tools um das Paket builden zu können. Da ich ein neues chroot Environment aufgesetzt hatte, war noch nicht alles da - zum Beispiel fehlte mir cdbs, ein sehr mächtiges (und mitlerweile viel benutztes) Tool zur einfachen Erstellung von Debian Paketen. Das hatte ich schon mal vorher portiert, aber ich dachte mir die Gelegenheit sei günstig da mal eine aktuelle Version zu bauen.
Dachte ich. Fing auch ganz harmlos an - es braucht für die Dokumentation springgraph - ein Tool zur Formatierung von Grafen. Das Tool selber hat eigentlich keine Builddependencies (ausser den obligatorischen Debhelpern). Fein. Baut auch sehr schnell. Bei der Installation meckert es dann über fehlende Perlmodule für die GD2 Einbindung. Ok, Perlmodule zu portieren ist oft nervig, aber dieses sah eigentlich ganz simpel aus. Eine Reihe von Buildabhängigkeiten, klar, aber sonst harmlos. Bis auf den Fakt, das es zum Builden cdbs braucht.
Aaaaarghl!!!!
Okok, ich weiss was man machen muss. Trotzdem. Manchmal hab ich das GefĂĽhl die Debian-Maintainer setzen sich heimlich zusammen um mich in den Wahnsinn zu treiben
