Es stellte sich nach Auswertung eines Netzwerkdumps heraus, dass die Shopseite eine Anfrage über den XMLRPC-Server erhält, aber nie auf den Request antwortet. Als das Zeit- und Speicherlimit für PHP, die üblichen Verdächtigen in solchen Fällen, ausgeschlossen waren, sahen wir, dass der Konnektor suboptimale Anfragen an die Datenbank stellt und diese somit schwer arbeiten musste. Die angefragten 500 Artikel können so nicht rechtzeitig geliefert werden und die Gegenseite bricht den Versuch ab.

Da der Kunde eine schnelle Lösung benötigt, um die neusten Produkte zu synchronisieren, beschränkten wir den Abgleich auf 350 Artikel. Weiterhin unterbreiteten wir ihm den Vorschlag das Problem durch geschicktere Datenbankanfragen und Caching der Ergebnisse  komplett aus der Welt zu schaffen um die volle Funktionalität wiederherzustellen.

Falls Sie auch Unterstützung bei der Anbindung eines ERP-Systems an Magento  oder der Anpassung am Shop benötigen, nehmen Sie Kontakt mit uns auf und wir helfen Ihnen gerne weiter.

Für die Untersuchung der Seite boten sich die Webseiten GTmetrix und WebPagetest an. GTmetrix fasst die Ergebnisse von YSlow und Google PageSpeed zusammen und als Bonus speichert es alte Messungen zum Vergleich der verschiedenen Optimierungen. Die Seite WebPagetest überzeugt mit aussagekräftigen Wasserfall und Verbindungsdiagrammen.

Bei der Analyse zeigte sich, dass das Rendern der Seite mehr als 15 Sekunden benötigt und diese Seite mehr als 1.1 MB an initialen Daten benötigt. Als Ziel setzte der Kunde 6 Sekunden zum Rendern der Seite. Das sahen wir auch als realistisch an.

Beispiel eines Verbindungsdiagramms

Im Wasserfalldiagramm stellt sich die TTFB (Time To First Byte) als größter Posten dar und dort begannen wir auch mit unserer Arbeit. Nach eingehender Analyse der momentanen Systems zeigte sich auf PHP-Seite, dass der APC Bytecode Cache mit 12MB zu klein dimensioniert war und PHP per FCGI eingebunden ist.

Der kleine Cache sorgte für eine schnelle Verdrängung von Cacheeinträgen. Dies führt zu einer Hit / Miss Rate von 20 / 80. Da jeder FCGI Prozess seinen eigenen Bytecode Cache benötigt, wird bei der Nutzung von APC für den Magento Cache zusätzlicher Platz benötigt. Wir splitteten den Mangento Cache und Bytecode Cache in zwei verschiedene Systeme. Der APC-Cache ist mit 128MB bemessen und sorgt für das Cachen des Bytecodes. Der Magento Cache wird jetzt durch einen Memcached-Server mit 256MB übernommen. Durch diese Maßnahme kann der Kunde später durch neue Server horizontal skalieren und hat einen gemeinsamen Cache für alle Instanzen. Die TTFB war damit bei einem Drittel der ursprünglichen Zeit und die Hit- / Missrate für den APC- und Bytecode-Cache bei 99/1.

Die Begutachtung des Seiten-HTML-Codes förderte zu Tage, das Boxen mit aktuellen Angebote per iframe eingebunden wurden. Dies sorgte beim Laden der Seite für ein ständiges Neurendern und verzögerte den subjektiven Seitenaufbau. Die diversen iframes konsolidierten wir zu einem einzigen, der bereits von Magento an der richten Stelle im Template eingebunden wird.

Die Verbindungsanalyse von GTmetrix zeigte, das viele Bilder/CSS/JS Dateien sequenziell geladen werden müssen und nur eine begrenzte Anzahl von Verbindungen zum Server aufgebaut werden. Dies lösten wir durch Aktivieren von HTTP-Pipelining im Apacheserver und Aufteilung der js, media und skin Verzeichnisse auf verschiedene vHosts. Beispielhaft nachzulesen ist das in einem Blogeintrag zum Thema Hostplitting.

Beispiel eines Wasserfalldiagramms

Als letztes widmeten wir uns dem Thema Trafficreduzierung. Dazu ließen wir Magento alle CSS- und JS-Dateien jeweils in eine Datei zusammenfassen und diese mit einem CSS- und JS-Minifier weiter komprimieren, die Produktbilder von Magento auf die korrekte Größe skalieren.

Weiterhin verkleinerten wir die Bilder ohne Qualitätseinbußen durch das Tool in Googles Pagespeed.  Die GZip-Kompression aller textuellen Ressourcen und das Setzen eines Expires-Headers durch den Apache Server brachte noch einmal einen deutliche Geschwindigkeitssteigerung und Trafficreduzierung bei weiteren Zugriffen auf die Seite.

Desweiteren setzten wir alle einfach zu erreichenden Vorschläge von YSlow und Googles Pagerank um.

Das Ergebnis der Mühe ist ein Shop, der in 4.5 Sekunden lädt.  Der benötigte Traffic für die Seite sank dabei von 1.1MB auf 590KB. Das YSlow-Ranking wuchs von  67% auf 80% und das PageSpeed-Ranking von 75% auf 93%.

Wir legten dem Kunden dar, dass er die Ladezeit von 4.5s weiter reduzieren könnte, da dort 2.5s als TTFB enthalten sind. Dies könnte er durch geschicktes Caching mittels eines Reverse Proxy wie beispielsweise Varnish erreichen. Das Laden des statischen Contents könnte weiterhin auch durch einen leichtgewichtigeren Webserver wie lighttpd oder nginx noch beschleunigt werden. Der Kunde ist mit dem erreichten Zustand sehr zufrieden und priorisiert momentanen andere Projekte höher.

Falls auch Sie Hilfe bei der Beschleunigung ihres eCommerce Portals benötigen, stehen wir Ihnen gerne mit Rat und Tat  zur Seite. Fordern Sie uns ! Wir lieben Herausforderungen. Nehmen Sie einfach über das Kontaktformular mit uns Kontakt auf und wir melden uns bei Ihnen.

The only thing you have to do is to add the following PPA to your Ubuntu installation and update the repository afterwards (Ubuntu Karmic and Later)

sudo add-apt-repository ppa:rabbitvcs/ppa
sudo apt-get update

followed by a

sudo apt-get install «packages»

Aavailable packages are:

rabbitvcs-nautilus3 for the Nautilus 3.x extension
rabbitvcs-nautilus for the Nautilus 2.x extension
rabbitvcs-thunar for the Thunar extensions
rabbitvcs-gedit for the GEdit extension
rabbitvcs-cli for the command line launchers

We tested the nautilus integration and the gedit extension on both versions of Ubuntu and all work like a charm !

Thanks a lot to the RabbitVCS community for having put that project on the track.

Additional extra suggested by WebUpd8 is to re-add the icons to the nautilus menu

Prior to Oneiric you hav run

gconf-editor

on the console and check

“desktop”->”gnome”->”interface”->”menu_have_icons”

starting from Oneiric you have to use the new by just typing

dconf-editor

on the console to check

“org”->”gnome”->”desktop”->”interface”->”menu_have_icons”

Im Moment werden nur bei neuen Issues alle konfigurierten Benutzer informiert. Dabei ist es durch Konfigurationsoptionen auch möglich den Reporter und den Bearbeitenden auszusparen. Es wird sicherlich mit neuen Anforderungen wachsen und genereller werden. Das aktuelle Plugin ist bei GitHub zu finden. Über Patches, Kommentare und Feedback würden wir uns natürlich freuen.

Dieses Tool findet ihr auf GitHub:

https://github.com/OSguard/Magento-Query-Builder

Das Beispiel:

https://github.com/OSguard/Magento-Query-Builder/blob/master/example_export_all_products.php

erklärt im Wesentlichen, wie man das Script benutzen kann. Man erzeugt sich ein Objekt, auf das man zugreifen will und lädt die Attribute:

$builder = new QueryBuilder('catalog/product', array(0,1));
$builder->loadAllAttributes();

Danach wählt man aus, welche Attribute man ausgeben will:

$attr = array(
    "entity_id",
    "sku",
    "name",
    "price",
    "url_path",
    "url_key",
    "attribute_set",
    "status",
    "created_at",
    "updated_at"
    );
 
 
$builder->selectAttributes( $attr );

Man kann z.B. noch die Bedienung einschränken, damit eine WHERE-Klausel gebaut wird:

$builder->setCond( 'type_id', '=', '"simple"');

Dann kann man sich das Query ausgeben lassen:

$builder->getQuery();

In unserem Beispiel wird dann folgender SQL-Befehl erzeugt:

SELECT a.entity_id AS entity_id,
 a.sku AS sku,
 t0.VALUE AS name ,
 t1.VALUE AS price ,
 t2.VALUE AS url_path ,
 t3.VALUE AS url_key ,
 b.attribute_set_name AS attribute_set,
 t4.VALUE AS STATUS ,
 a.created_at AS created_at,
 a.updated_at AS updated_at
	FROM
	(
	SELECT
		entity.*
	FROM 
		catalog_product_entity entity 
        WHERE 
                entity.type_id = "simple"   ) a
		    LEFT JOIN
			eav_attribute_set b
		    ON
			b.attribute_set_id=a.attribute_set_id
		    LEFT JOIN 
                        catalog_product_entity_varchar t0
                        ON 
                        t0.attribute_id= 96 AND
                        t0.entity_id=a.entity_id AND
                        t0.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_decimal t1
                        ON 
                        t1.attribute_id= 99 AND
                        t1.entity_id=a.entity_id AND
                        t1.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_varchar t2
                        ON 
                        t2.attribute_id= 570 AND
                        t2.entity_id=a.entity_id AND
                        t2.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_varchar t3
                        ON 
                        t3.attribute_id= 481 AND
                        t3.entity_id=a.entity_id AND
                        t3.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_int t4
                        ON 
                        t4.attribute_id= 273 AND
                        t4.entity_id=a.entity_id AND
                        t4.store_id = 0

Das ist keine fertige Bibliothek, die man in ein Modul einbauen kann. Aber mann kann damit z.B. Export-Scripte bauen, die auch sehr viele Produkte in Sekunden exportieren, da hier der Magento-Weg sehr langsam ist. Oder es erleichtert das Arbeiten auf der Datenbank-Konsole. Zur Zeit ist das noch eine Rohfassung, vielleicht findet sich ja der ein oder andere, der bei der Entwicklung hilft. Der Code steht unter BSD-Lizenz.

Vorwort

Mit viel Aufwand hat die Firma DATEV e.G. mit Hauptsitz in Nürnberg, das deutschlandweit erste Unternehmen, das überhaupt derartige Software angeboten hat, den Schritt in das Zeitalter voll-integrierter Anwendungssysteme gemacht. Bis dato bestand Datev aus wenig bis gar nicht integrierten Insellösungen für die unterschiedlichen Geschäftsprozesse, darunter Programme für die Lohnbuchhaltung (LODAS), Einkommenssteuererklärung (ESt), die Kanzleiorganisation (Eigenorganisation) und das Rechnungswesen (Kanzlei ReWe).

Bereits mit Beginn des Jahres 2010 hatte Datev angefangen, die Vorzüge des neues Produktes in entsprechender Weise zu präsentieren und die Kunden zu einer Umstellung zu bewegen. Eine im Rahmen der Einführung dieses Wochenende durchgeführte Befragung des First und Second Level Support von Datev zeigt jedoch, dass allen Bemühungen zum trotz vermutlich erst 1/3 aller Steuerberater, die Datev nutzen umgestellt haben. Dies ist insofern bedenklich, als dass ab dem 1.1.2012 keine Transaktionen der alten Programme mit den Rechenzentren von Datev und den Finanzbehörden mehr möglich sein wird. Datev hat hierzu mit bereits einjähriger Vorlaufzeit den Support abgekündigt.

Verlauf der Migration

Der Betrieb von 10 Arbeitsplätzen in der Kanzlei und 2 Remotenutzern (über VPN angeschlossen) bei unserem Kunden, läuft auf einem leistungsfähigen Hostserver der Marke Dell mit Windows 2008 Small Business Server, sowie einem darauf installierten Windows 2008 SBS Terminal Server. Dieser lößte bereits in einem letzten Ausbauschritt die früherer Client / Server Installation mit Servern und einer Vielzahl eigener Clients ab. Die Maintainance und Wartungskosten der Clientsysteme sind mit dieser Maßnahme erheblich gesenkt worden. Die Stabilität und Konistenz der Anwendungsnutzung konnte zudem durch die WTS-Umgebung gesteigert werden. Da in diesem Setup sowohl der Hostserver (der auch als Datenbankserver fungiert) alsauch der WTS-Server sogenannte “single points of failure” darstellen, wurde zur Migrationsvorbereitung beschlossen, ein komplett separates Offline Backup der Hostmaschine zu fahren. Nachdem alle Vorarbeiten erledigt waren und alles aktuellen Sicherheitsupdates der Plattform eingespielt waren, wurde deshalb eine vollständiges Backup der etwa 250GB Kanzleidaten durchgeführt. Da es sich bei derart großen Datenbeständen in Datenbanken zumeist um recht fragmentierte Daten handelt, dauerte diese Maßnahme gut 6 Stunden und erfolgte am Freitag Nachmittag und in der Nacht zum Samstag.

Am Samstag wurde dann morgens mit der Basisinstallation des Fileservers begonnen. Zu diesem Zweck stellt Datev eine Reihe von Leitfäden bereit, deren Lektüre zur Fehlervermeidung dringend anzuraten ist. Besonders hilfreich war, dass die Firma Datev e.G. als einer der letzten Softwarehäuser in Europa dazu durchringen konnte ihren Support zumindest zeitlich an die üblichen Zeitfenster für Updates und Migrationen anzupassen und eine Hotline auch am Wochenende anzubieten. Dies war besonders bei der notwendigen Datenbereinigung der Nummernzusammenhänge im Vorfelde der Datenübernahme sehr hilfreich.

So konnte sichergestellt werden, dass die circa 1500 Mandantenstammdatensätze ohne ein gravierendes Problem übernommen werden konnten. Ein ewiger Problempunkt bei Datev ist das Softwareschutzmodul und die damit recht eng verzahnte Nutzungskontrolle sowie DFÜ-Übertragung. Auch hier war jedoch ein Supporttechniker sehr hilfreich. Sehr kritisch anzumerken ist, dass die Wartezeiten der Supporthotline von Datev nach wie vor unzumutbar sind. Die Qualität des Services und die Kompetenz mit der beraten wurde waren jedoch vorbildlich

Nach der Migration

Die Kanzlei hat bereits mit der letzten Version von Datev Classic die Officelösung Open Office eingesetzt und damals eine Menge Aufwand betrieben, die offensichtlich unzureichend getestete Schnittstelle zur korrekten Arbeit mit Datev zu bewegen. Nach einer schwierigen Anlaufphase (Laufzeitproblemen) konnte das Produkt jedoch erfolgreich mit Datev Classic genutzt werden. Umso ärgerlicher ist es daher, dass die Installationsroutine von Datev Pro oder besser die stets vorher durchlaufende Anforderungsprüfung ein rote Ampel liefert, wenn kein Microsoft Office installiert ist, obwohl Open Office in der Version 3.3 zumindest für die wichtigsten Schriftwechsel offiziell freigegeben ist.

Die deuten wir als Zeichen dafür, dass Datev nach wie vor Open Office bzw. seinen Fork (LibreOffice) unzureichend bzw. gar nicht unterstützen. Hier ist nach wie vor erhebliches Verbesserungspotential. Ebenso ärgerlich ist, dass nach der Fertigstellung der Installation eine Neuanlage von Dokumenten mit Open Office fehlschlägt und eine Fehlermeldung geworfen wird. Daran ändert auch eine Prüfung der Einstellungen mit dem Office Konfigurationsdialog von Datev “OfficeDiag.exe” nichts. Es bleibt abzuwarten ob der Fehler am Montag morgen zeitnah bereinigt werden kann.

Erster Eindruck

Sowohl der Kunde, als auch wir als IT-Dienstleister konnten direkt im Anschluss der Installation und Erstbestückung des Arbeitsplatzes Pro von Datev (hierbei ist darauf zu achten, dass der installierende Nutzer auch Nuko Admin ist) das deutlich intuitiver zu bedienende Dashboard von Datev Pro bewundern. Die Kommunikation (Email und CTI) ist jetzt nahtlos integriert und erlaubt eine schnelle Kontaktaufnahme mit den Mandanten. Die Termin- und Aufgabenverwaltung ersetzt einen Exchangeserver weitgehend (obwohl der Datenabgleich möglich wäre) und verringert so die Umstiegshürden von MS-Office auf Open Office, da letzteres leider nicht über einen Rich Mail Client verfügt. Auch die Dokumentenorganisation ist recht intuitiv zu bedienen und kann direkt am Kunden abgelegt werden. Im Anschluss an die Installation wurde beschlossen die Anbindung der Email-Kommunikation künftig über Thunderbird und die IMAP Funktion des installierten Exchange 2007 Servers zu realisieren. Damit ist sichergestellt, dass der Mailverkehr in einem zentralen Mailstore gespeichert wird und so auditsicher verwahrt werden kann. Zeitgleich können so Handlingproblem insbesondere bei den zum Teil großen Attachements deutlich reduziert werden, da der Webclient von Exchange 2007 hier nach wie vor Schwächen hat.

Fazit und Resümee

Die Tatsache dass der Arbeitsplatz Pro der zentrale Anlaufpunkt für alle kanzleispezifischen Prozesse geworden ist, hängt für die nun folgende Schulungs- und Einführungsphase die Erwartungshaltung sehr hoch. Wermutstropfen ist und bleibt die schlechte Perfomance vieler auf .NET Basis entwickelter Anwendungen. Dieses bereits von Sage Office Line Evolution bekannte schleppende Laufzeitverhalten, scheint ein grundsätzliches Problem auch von Datev Pro zu sein bzw. zu werden. Dennoch erwarten der Steuerberater als auch wir einen deutliche Effizienzsteigerung der Kanzleiprozesse nach dieser Umstellung. Wir ziehen insgesamt ein positive Resümee der Migration und konnten zumindest die auch von uns vorher geäußerten Vorbehalte weitgehend ausräumen. Bewahrheitet sich der erste Eindruck auch in der Praxis und gelingt es der Datev insbesondere beim Support und dem Laufzeitverhalten sowie der Unterstützung offener Standards noch ein deutliches Quäntchen nachzulegen, dürften DATEV neuerlicher Erfolg beschieden sein. Ein kritischer Punkt werden sicherlich die geballten noch ausstehenden Migrationen zum Jahreswechsel 2011/2012.

• Webservice url the URL to the SOAP API of Mantis
• Username a valid Mantis user, you have to try whether you need a Manager-User or whether a Developer just works, this depends on your Mantis installation
• Password of the user
• Project ID the default mantis project that you want to use in Joomla, you can override this by menu entry
• Backup Email sends the data of form to this email if mantis SOAP is not working
• use captcha use the JCCReCaptcha Plugin to protect your form
• Secret Key random string to encrypt your mantis id in the url (weak encryption)
• overview enable/disable the link from the form back to the overview of all bugs of the selected project

Eine Auswertung des SQL-Query-Logs ergab erstmal nichts auffälliges, der ganze Prozess zur Indexerstellung lief in einer Transaktion ab. Bei einem genauen Blick und sorgfältiger Analyse stellte man fest, dass Magento im Model Mage_Index_Model_Mysql4_Abstract den SQL-Befehl “ALTER TABLE {$destTable} DISABLE KEYS” immer ausführt, auch wenn die Storage-Engine von MySQL InnoDB ist. Diese Zeile existiert, um das nachfolgende INSERT zu beschleunigen, dies ist aber nur bei MyISAM notwendig. Unter InnoDB sorgt es dafür, dass ein implizierter Commit gemacht wird und damit die Indextabelle erstmal leer ist. Das Überschreiben des Models hat das Problem gelöst.

In der aktuellen Magento-Version ist das Problem behoben, aber nicht jeder will und kann seinen Shop gleich updaten.

Besonders zu beachten ist, dass der Einsatz eines Webanalyse-Tools nicht gegen deutsche Datenschutzgesetze verstoßen darf, weswegen z.B. Google Analytics umstritten ist .

Piwik ist eine Open-Source Webanalyse-Software, die datenschutzkonform eingesetzt werden kann wie zum Beispiel Heise unlängst berichtete.

Die Vorteile von Piwik sind:

• Die Statistiken werden in Echtzeit erstellt.
• Piwik ist eine Software, die auf dem eigenen Server installiert wird. Die Daten, die von Piwik erhoben werden, befinden sich in einer Datenbank unter eigener Kontrolle und werden nicht wie etwa bei Google auf U.S. Servern gespeichert.
• Die Bedienoberfläche kann vollständig den eigenen Bedürfnissen angepasst werden.

Piwik lässt sich auf der eigenen Webseite ganz einfach durch Einfügen eines Javascript-Codeschnipsels integrieren.
In der aktuellen Version 1.6 bietet Piwik folgende Möglichkeiten zum datenschutzkonformen Einsatz:

• Anonymisierung der IP-Adressen der Besucher durch das Plugin AnonymizeIP.
• Alte Besucherdaten lassen sich in regelmäßigen Abständen automatisch aus der Datenbank löschen.
• Einfügen eines Codes auf der Webseite, der die Deaktivierung der Webanalyse durch den Besucher erlaubt.

Ein Beispiel für die Einbindung der Deaktivierungsmöglichkeit findet sich auf dieser Webseite im Impressum.

Piwik lässt sich auch in Verbindung mit eShops verwenden. marmalade.de hat ein Piwik-Plugin für den OXID eShop veröffentlicht, weitere Infos dazu befinden sich hier.

Ein Piwik-Plugin für Magento findet man hier.

Ein Beispiel wäre, wenn man Zubehör und dem eigentlichen Produkt jeweils unterschiedliche Kriterien zuordnen will.

Dabei reicht eine einfache Änderung im Template aus:

<?php 
    $product = $this->getProduct();
    $attributeSetModel = Mage::getModel("eav/entity_attribute_set");
    $attributeSetModel->load($product->getAttributeSetId());
    $attributeSetName  = $attributeSetModel->getAttributeSetName();
    foreach ($this->getRatings() as $_rating): ?>
        <?php 
	// Wenn kein Zubehör, dann kein Zubehör anzeigen
        if( strpos($_rating->getRatingCode(),"Zubehör") !== false && 0 != strcmp($attributeSetName, 'Zubehoer') ){
              continue; 
        }
        // Wenn Zubehör, dann nur Zubehör anzeigen
        if( strpos($_rating->getRatingCode(),"Zubehör") === false && 0 == strcmp($attributeSetName, 'Zubehoer') ){
              continue; 
        }
        ?>

Diese Änderung nimmt man in Advancereview/review/form.phtml seines Templates vor.