Archiv 19. Januar 2005

Beitrag 4000

Wow. Das hier ist - in der derzeitigen Datenbank - der 4000ste Artikel

erstauntes Gesicht

bigempty.com ist ein sehr schönes Fotoblog mit einem sehr minimalistischen Design. Ein nettes Gimmick: die Hintergrundfarbe des Fussbereiches orientiert sich am angezeigten Foto - keine Ahnung ob es automatisch berechnet wird, aber die Idee ist nett.

Bundesgrenzschutz heißt bald Bundespolizei - war da nicht mal was von wegen Verbot einer Bundespolizei für Deutschland? Egal, auch diese letzte Schamgrenze fällt.

Fotos folternder Soldaten im Irak schockieren die Briten - aber werden sie deshalb ihrem Premier die Meinung sagen? Und wichtiger: wird Blair jetzt endlich von dem Wahnsinn Abstand nehmen? Oder wenigstens für die Zukunft daraus lernen und den Iran-Wahnsinn nicht mitmachen, der sich bei den Amerikanern so langsam andeutet?

Got New Spam Tactic Figured

Asymptomatic » Got New Spam Tactic Figured berichtet übert eine neue Taktik der Blogspammer. Und zwar tauchen relativ harmlose Kommentare auf Blogs auf, die keinen einzigen Link enthalten. Wenn die Spammer diese Kommentare über Google wiederfinden wissen sie, das sie dort höchstwarscheinlich weitere Kommentare ablassen können - und umgehen die Sperren, die darauf beruhen das ein Kommentar automatisch freigegeben wird wenn ein Besucher unter seiner eMail-Adresse schon mal einen freigegebenen Kommentar hatte. Es könnte also sein das nach einem Hey, Deine Seite finde ich toll Kommentar dann plötzlich ein Berg von Blogspam aufschlägt ...

Offenbar härtere Strafen für Drängler geplant - halte ich auch für dringend angebracht. Ich krieg jedesmal die Krise wenn wir mal auf der Autobahn unterwegs sind. Das ist doch pervers, was sich da einige hinterm Steuer erlauben ... (und nein, wir gehören weder zu den notorischen Linksfahrern noch zu den lahmen schleichern)

RSS 1.1: RDF Site Summary (DRAFT)

RSS 1.1: RDF Site Summary (DRAFT) - wie sinnvoll. Irgendjemand hat sich RSS 1.0 (ja, dieses ungeliebte RDF-basierte Format das eigentlich keiner so richtig kennt) und dazu einen Update entworfen. Weil, es gibt ja noch nicht genug Feed-Formate, da muss man ja unbedingt noch eins dazu packen.

Passend dazu bin ich dann auch noch über das HTML Syndication Format gestolpert - auch so eine sinnvolle Sache, da hat sich jemand gedacht den Feed einfach als speziell getaggten XHTML Source auszuliefern.

Und im Gegensatz zur RSS 3.0(das auf YAML basiert statt auf XML) meinen die anderen beiden es wohl mehr oder weniger ernst (beim HTML Syndication Format hoffe ich ja immer noch das es nur eine aufwändig gestaltete Ente war ...)

Schwarzenegger lehnt Gnadengesuch ab

Der Terminator macht seinen Filmfiguren alle Ehre - und schickt mal wieder einen Menschen in den Tod.

Sicher und anonym im Internet mit Proxys - Anleitung zur Nutzung von Privoxy und tor. Hatte ich irgendwie noch nicht hier verlinkt. Ist so gut, sollte man lesen. Wird man nicht dümmer von.

Subtraction: New, Improved Original Flavor!

Khoi Vinh stellt sein neues Design vor. Irgendwie cool wie er durch Weglassen einen - für mich - recht interessanten Eindruck produziert. Mir gefällt es jedenfalls sehr gut.

Ich wär ja froh wenn ich mal ein eigenes Design hinkriegen würde und meine Designs nicht immer irgendwo klauen müsste ... (einer der echten Vorteile von WordPress - das Kubrick Design mag ja mitlerweile etwas weit verbreitet sein, aber es lässt sich wenigstens auch von Design-Daus wie mir anpassen ohne das einem alles um die Ohren fliegt)

WordPress NoFollow Plugin

Das WordPress NoFollow Plugin versieht Links in Kommentaren mit dem rel="nofollow" um ihnen das Google-Ranking zu nehmen. Wobe ich persönlich daran schade fände, das dann generell Links nicht mehr von den Kommentaren gefolgt wird - und damit gerade die für kleinere Blogs brauchbare Möglichkeit durch aktive Diskussion in anderen Blogs das eigene zu promoten wegfällt. Ok, letzten Endes ist das auch nicht so schlimm, aber irgendwie geht schon ein kleines Stückchen der Ein Link wäscht den Anderen Mentalität der Blogs verloren ... Ein kleines Handicap ist, das der Autor das Plugin direkt verlinkt hat und dummerweise sein Server das PHP direkt ausführt. Im Moment kann man es also nicht runterladen, man kriegt nur eine leere HTML Seite

Zope Hosting and Performance - English Version

Somebody asked for an english translation of my article on Zope Hosting and Performance. Here it is - ok, it's not so much a direct translation than a rewrite of the story in english. Enjoy.

Recently the Schockwellenreiter had problems with his blog server. He is using Zope with Plone and CoreBlog. Since I am doing professional Zope hosting for some years now, running systems that range in the 2000-3000 hits per minute scale, I thought I put together some of the stuff I learnt (sometimes the hard way) about Zope and performance.

  • The most important step I would take: slim down your application. Throw out everything you might have in the Zope database that doesn't need to stay there. If it doesn't need content management, store it in folders that are served by Apache. Use mod_rewrite to seemlessly integrate it into your site so that people from the outside won't notice a difference. This can be best done for layout images, stylesheets etc. - Apache is much faster in delivering those.
  • Use Zope caching if possible at any rate. The main parameter you need to check: do you have enough RAM. Zope will grow when using caching (especially the RAMCacheManager). The automatic cleanup won't rescue you - Zope will still grow. Set up some process monitoring that automatically kills and restarts Zope processes that grow above an upper bound to prevent paging due to too large memory consumption. This is even a good idea if you don't use caching at all.
  • There are two noteable cache managers: one uses RAM and the other uses an HTTP accelerator. The RAMCacheManager caches results of objects in memory and so can be used to cache small objects that take much time or much resources to construct. The HTTPCacheManager is for using a HTTP accelerator - most likely people will use Squid, but you can use an appropriately configured Apache, too. The cache manager will provide the right Expires and Cache-Control headers so that most traffic can be delivered our of the HTTP accelerators instead of Zope.
  • Large Zope objects kill Zopes performance. When using caching they destroy caching efficiency by polluting the cache with large blobs of stuff that isn't often required and Zope itself will get a drain in performance by them, too. The reason is that Zope output is constructed in-memory. Constructing large objects in memory takes much resources due to the security layers and architectural layers in Zope. Better to create them with cronjobs or other means outside the Zope server and deliver them directly with Apache. Apache is much faster. A typical situation is when users create PDF documents in Zope instead of creating them outside. Bad idea.
  • Use ZEO. ZEO rocks. Really. In essence it's just the ZODB with a small communication layer on top. This layer is used in Zope instances instead of using the ZODB directly. That way you can run several process groups on your machine, all connecting to the same database. This helps with the above mentioned process restarting: when one is down, the other does the work. Use mod_backhand in Apache to distribute the load between the process groups or use other load balancing tools. ZEO makes regular database packs easier, too: they run on the server and not in the Zope instances - they actually don't notice much of the running pack.
  • If you have, use a SMP machine. Or buy one. Really - that helps. You need to run ZEO and multiple Zope instances, though - otherwise the global interpreter lock of Python will hit you over the head and Zope will just use one of the two processors. That's one reason why you want multiple process groups in the first place - distribution of load on the machine itself, making use of multiple processors.
  • You can gain performance by reducing the architectural layers your code goes through. Python scripts are faster than DTML. Zope products are faster than Python scripts. Remove complex code from your server and move it into products or other outside places. This needs rewriting of application code, so it isn't allways an option to do - but if you do, it will pay back.
  • Don't let your ZODB file grow too large. The ZODB only appends on write access - so the file grows. It grows quite large, if you don't pack regularily. If you don't pack and you have multi-GB ZODB files, don't complain about slow server starts ...
  • If you have complex code in your Zope application, it might be worthwile to put them into some outside server and connect to Zope with some RPC means to trigger execution. I use my |TooFPy| for stuff like this - just pull out code, build a tool and hook it into the Zope application via XMLRPC. Yes, XMLRPC can be quite fast - for example pyXMLRPC is a C-written version that is very fast. Moving code outside Zope helps because this code can't block one of the statically allocated listeners to calculate stuff. Just upping the number of listener threads doesn't pay as you would expect: due to the global interpreter lock still only one thread will run at a time and if your code uses C extensions, it might even block all other threads while using it.
  • If you use PostgreSQL, use PsycoPG as the database driver. PsycoPG uses session pooling and is very fast when your system get's lots of hits. Other drivers often block Zope due to limitations like only one query at a time and other such nonsense. Many admins had to learn the hard way that 16 listener threads aren't really 16 available slots if SQL drivers come into play ...

There are more ways to help performance, but the above are doable with relatively small work and are mostly dependend on wether you have enough memory and maybe a SMP machine. Memory is important - the more the better. If you can put memory into your machine, do so. There is no such thing as too-much-memory (as long as your OS supports the amount of memory, of course).

What to do if even those tips above don't work? Yes, I was in that situation. If you come into such a situation, there is only one - rather brutish - solution: active caching. By that I mean pulling stuff from the Zope server with cronjobs or other means and storing it in Apache folders and using mod rewrite to only deliver static content to users. mod rewrite is your friend. In essence you just take those pages that kill you currently and make them pseudo-static - they are only updated once in a while but the hits won't reach Zope at all.

Another step, of course, is more hardware. If you use ZEO it's no problem to put a farm of Zope servers before your ZEO machine (we currently have 5 dual-processor machines running the Zope instances and two rather big, fat, ugly servers in the background for databases, frontend with two Apache servers that look allmost like dwarves in comparisons to the backend stuff).

Zope is fantastic software - don't mistake me there. I like it. Especially the fact that it is an integrated development environment for web applications and content management is very nice. And the easy integration of external data sources is nice, too. But Zope is a resource hog - that's out of discussin. There's no such thing as a free lunch.