Wie im Auftakt-Eintrag beschrieben, handelt dieser Post von Maßnahmen und Erkenntnissen bei der Performance-Optimierung von Jython und Django.
Als erstes Testszenario für die Optimierung verwendeten wir eine normale Datenbankabfrage über den Django Object Relational Mapper (ORM). Read on »
Im Rahmen eines laufenden Projektes befassen wir uns mit der Performance-Optimierung von Jython. Hintergrund ist die Integration von Django in eine Java-Umgebung auf der Basis von Apache Tomcat.
Bei Jython handelt es sich um eine Umsetzung von Python in Java, welche als Bindeglied zwischen diesen Sprachen dient. In diesem Zusammenhang erweist sich die Erweiterung django-jython als sehr nützlich für das Deployment und den Datenbankzugriff von Django-Projekten. Mit django-jython kann ein Projekt einschließlich zugehöriger Bibliotheken über einen Django Management Command in eine .war-Datei kompiliert werden. Für das Deployment wird diese Datei nur noch dem Anwendungsserver – hier Apache Tomcat – übergeben.
Bei der Entwicklung für unser Projekt stellten wir wesentliche Geschwindigkeitsunterschiede zwischen Python und Jython fest. Das Laden einer Referenzseite mit umfangreichen Datenbankoperationen dauerte mit Python 1.5, mit Jython ganze 11 Sekunden. Somit lag die Notwendigkeit einer Optimierung der Geschwindigkeit auf der Hand. Unsere Maßnahmen und Erkenntnisse auf diesem Weg wollen wir in diesem und nachfolgenden Blogeinträgen weitergeben.
Ausgangspunkt für die Optimierung ist ein System in der Konfiguration Apache Tomcat 6.0.20, Jython 2.5.1 und Django 1.1. Um nicht in der Vergangenheit zu optimieren, wechselten wir Jython von stable auf trunk aus – die letzte veröffentlichte Version stammte vom September 2009. Zunächst wollte unser Django-Projekt nicht auf trunk laufen, Fehlermeldung:
java.lang.NoSuchMethodError: org.python.core.Py.makeClass(Ljava/lang/String;[Lorg/python/core/PyObject;Lorg/python/core/PyCode;Lorg/python/core/PyObject;)Lorg/python/core/PyObject;
Nach Identifikation des verursachenden Commits erwies sich der vermeintliche Bug als eine Änderung im Jython-Compiler. Für die Neukompilierung des Quellcodes mussten alle vorhandenen .class-Dateien gelöscht werden. Leichte Übung.
Die Umstellung von Jython stable auf trunk reduzierte die Laufzeit von besagten 11 auf immerhin 6 Sekunden. Nun konnte es an die eigentliche Optimierung gehen. Mehr dazu im nächsten Blogeintrag.
Ich hab jetzt auch noch das Meta SEO Pack deaktiviert und hoffe, dass jetzt mein Ping an Google wieder geht. Dieser Artikel ist damit auch gleich mein Testartikel.
Update: scheint funktioniert zu haben:
66.249.71.72 – - [11/Feb/2010:23:08:20 +0100] “GET /blog/index.php/2010/02/12/meta-seo-pack-wordpress-seo-plugins/ HTTP/1.1″ 200 11219 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
Seit ich die neuen SEO Plugins installiert hab, sind wir bei Google gar nicht mehr zu finden. Hab jetzt mal das Keyword Stat Plugin deaktiviert.
Dieser Post ist damit auch gleichzeitig ein Test, ob sich das jetzt ändert.
—
Wir geben mal wieder Wissen weiter: Am Samstag, den 20.02. veranstalten wir in kleiner Runde einen Vortrag über die Versionsverwaltung Git. Read on »
Mir wird nachgesagt, dass ich entweder massenhaft blogge oder gar nicht. Daher hier gleich der zweite Artikel…
Aufgrund aktuelle Entwicklung und der immer grösser werdenden Kunden, war die bisherige Struktur der Angebote (Word-Dokument mit Inhaltsverzeichnis und Marginalien als Teaser) nicht mehr ausreichend. Daher haben wir auf externe Anregung hin ein neues Format für unsere Angebote für IT-Projekte entwickelt. Read on »
Verursacht durch eine heutige Anfrage über unsere Webseite zu einem Webshop mit SAP habe ich mir ein wenig mehr unsere Meta Tags (description, keywords, title) in unserem WordPress dazu angeschaut. Dabei ist mit Hilfe des SenSEO-Plugins aufgefallen, dass alle WordPress – Inhalte keine solche Meta Tags haben. Read on »
Unter diesem Motto steht eine Kooperation zwischen Tschitschereengreen und ID Konsil. Ziel ist es mit Hilfe der Schnittstellen-Kompetenz unseres Partnersn die Grenzen zwischen verschiedenen Enterprise Applikationen (EPR, CRM etc.) zu überwinden und an ebendiesen durch spezialisierte und hochflexible Webapplikationen Mitarbeitern, Partnern und Kunden bessere Daten zur Verwendung und Bearbeitung zur Verfügung zu stellen. Genauere Details finden sich in unserem Newsbeitrag “Daten in Bewegung”.

… und weil wir so verliebt sind in diese Logo-vs.-Low-Budget-Ticket-Deals haben wir gleich das tausendgeniale re:publica 2010 logo in unsere Sidebar eingebunden! Wers noch nicht gesehen hat: