Als Vorwort sollte noch angemerkt werden, dass der normale TYPO3-Cache ausreicht, wenn man nur Content hat, der für alle Besucher gleich ist, also keine Daten an der Session oder an Rechten von FeUser hängen. Aber für aufwändigere Extensions muss man Action im Plug-In als ‘non-cacheable’ eintragen, was dafür sorgt, dass diese Seiten wieder sehr langsam sind.

Falls noch nicht geschehen, kann man den Extbase Cache ab TYPO3 4.6 noch in den Memcache verlegen, dies tut man indem:

$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['extbase_reflection'] = array(
    'backend' =>; 't3lib_cache_backend_MemcachedBackend',
    'options' =>; array(
        'servers' =>; array('localhost:11211'),
  )
);
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['extbase_object'] = array(
    'backend' =>; 't3lib_cache_backend_MemcachedBackend',
    'options' =>; array(
        'servers' =>; array('localhost:11211'),
  )
);

in die localconf.php eingefügt wird.

Des Weiteren sollte man in seinen Models genau darauf achten, dass überall Lazy-Loading für die Relation aktiviert ist. Dies wird durch die Annotationen mit “@lazy” ergänzt. Dies sieht dann so aus:

 /**
  * Contact Informations
  * @lazy
  * @var Tx_Initos_Domain_Model_Contact
  */
  protected $contact;

Eine weitere Analyse der PHP Ausführung zeigt, dass die Anteile vom Code in der Regel so aufgeteilt sind:

• 40% Extbase Framework
• 20% eigene Extension
• 40% Fluid Template

Dies zeigt, dass die falsche Verwendung von Extbase oder Fluid schnell auf die Performance durchschlagen. Da hilft es nur, geschickt Funktionalität im Controller abzufangen bzw. sich eigene ViewHelper zu definieren um komplexe Schachtelungen von mit und zu unterbinden. Hier kommt man nicht um eine Code-Analyse herum.

Ein weiterer wichtiger Baustein ist, die eigene Extension um einen eigenen Cache zu erweitern. Hierfür gibt es schon eine Anleitung im TYPO3 Wiki.

Wenn Sie mit der Performance von TYPO3 nicht zufrieden sind, analysieren wir für Sie gerne das Problem und beheben es. Nehmen Sie einfach mit uns Kontakt auf.

Anmerkung:
Bei der Performance-Analyse zeigt sich, dass vor allem der Persistence Layer von Extbase sehr langsam ist. Aber wie wir schon erfahren haben, soll in der nächsten Version von Extbase noch mehr Performance rausgeholt werden.

Der HauptViewHelper sieht dann so aus:

require('fpdf/fpdf.php');
 
class Tx_Initos_ViewHelpers_FpfdViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
 
    public function render() {
        $pdf = new FPDF();
 
        $this->templateVariableContainer->add('fpdf', $pdf);        
 
        $this->renderChildren();
 
        $pdf->Output('Report', 'I');
 
        $this->templateVariableContainer->remove('fpdf');
 
        exit();
    }
}

Danach braucht man einen einfachen Helper, um Seiten anzulegen:

class Tx_Initos_ViewHelpers_P_PageViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
 
    public function render(){
        $fpdf = $this->templateVariableContainer->get('fpdf');
        $fpdf->AddPage();
 
        $this->renderChildren();
    }
 
}

Und einen ViewHelper, um den Text zu erzeugen:

class Tx_Initos_ViewHelpers_P_TextViewHelper extends cTx_Fluid_Core_ViewHelper_AbstractViewHelper {
 
    /**
     * 
     * @param string $text
     * @param int $width
     * @param int $height
     */
    public function render($text, $width, $height){
        $pdf = $this->templateVariableContainer->get('fpdf');
 
        $pdf->SetFont('Times','I',30);
        $pdf->SetTextColor(0,0,0);
        $pdf->Ln(10);
        $pdf->Cell($width, $height, utf8_decode($text)c, 0, 1, 'L');
 
        $this->renderChildren();
    }
 
}

Danach kann man sich ein FluidTemplate bauen:

<f:section name="main">
    {namespace initos=Tx_Initos_ViewHelpers}
    <initos:fpdf>
       <initos:p.page>
            <initos:p.text text="Hallo World!" width="120" height="20" />
       </initos:p.page>
    </initos:fpdf>
</f:section>

So kann man die gewohnte Fluid-Syntax verwenden, um PDFs zu erstellen, erhält ein übersichtliches Template und vermeidet Code-Doppelungen. Auf zum Weiteren FPDF-ViewHelper bauen.

Die initiale Optimierung bestand im Installieren eines PHP-Bytecode-Caches. Da die Ubuntu-LTS-Version kein aktuelles APC mitbringt, installierten wir über “pecl install apc” die neuste Version und aktivierten sie für die Apache Instanz. Die Größe des Caches erhöhten wir durch eintragen der Zeile “apc.shm_size=128M” in der Datei “/etc/php5/conf.d/apc.ini” auf 128MB und im selben Moment erhöhten wir auch die Anzahl des allokierbaren Shared Memories auf 256MB. Dies geschieht für das laufende System durch ausführen von “echo 268435456 > /proc/sys/kernel/shmmax”. Die Änderung wird durch einen Eintrag in die Datei /etc/sysctl.conf über einem Systemneustart persistent gemacht: ”kernel.shmmax=268435456″.

Im nächsten Schritt behoben wir die  wichtigsten Google PageSpeed Meldungen.  Das größte gemeldete Problem waren die fehlenden Cacheheader für Bilder. Durch das Kommando “a2enmod expires” wird das Modul zum Setzen von Cacheheadern aktiviert und ein Eintrag von:

ExpiresActive On
ExpiresDefault "access plus 1 month"

in der Datei “/etc/apache2/mods-enabled/expires.conf” sorgt dafür, dass alle statischen Inhalte für mindestens einen Monat ab dem Zugriff gecached werden. YSlow empfahl noch das deaktivieren des FileETag-Headers, was wir durch Eintrag “FileETag none” in der Datei “/etc/apache2/httpd.conf” auch taten.

Unser letzter Schritt bestand im Aktivieren des  installierten Memcached-Servers als Backendcache. Dies wird in der Datei “typo3conf/localconf.php” der TYPO3 Installation durchgeführt, durch Eintragen der Zeilen:

//use memcached backend as cache
$TYPO3_CONF_VARS['SYS']['useCachingFramework'] = '1';
 
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['backend'] = 't3lib_cache_backend_MemcachedBackend';
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['options'] = array(
 'servers' => array('localhost:11211'),
 );
 
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['backend'] = 't3lib_cache_backend_MemcachedBackend';
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['options'] = array(
 'servers' => array('localhost:11211'),
 );
 
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['backend'] = 't3lib_cache_backend_MemcachedBackend';
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['options'] = array(
 'servers' => array('localhost:11211'),
 );
 
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['dbal'] = array(
    'backend' => 't3lib_cache_backend_MemcachedBackend',
    'options' => array(
        'servers' => array('localhost:11211'),
    )
);

Der Kunde war mit der erreichten Performance zufrieden und wir boten ihm noch weitere Optimierungen an:

• Optimierung des MySQL-Servers
• Aufteilen der Bilder- und JS-Dateien auf unterschiedlicher Domains
• Nutzung eines schnelleren Webservers wie nginx für statische Inhalte
• Nutzung von Varnish als Reverse Proxy

Diese Vorschläge will er eventuell in der Zukunft adaptieren.

Erstens erlaubt es Hyper-V als Einzige der prominenten Virtualisierungstechnologien (KVM, XEN, VMware) nicht, mehr Speicher an die Clients zuzuweisen, als dem Host insgesamt zur Verfügung steht (sogenanntes Memory Overcommitment). Zum anderen scheint selbst das Zuweisen real existierender Ressourcen lausig implementiert zu sein.

Grundauslastung des Hyper-V Hosts

Will man auf einem mit 24 GB ausgestatteten Windows 2008 Small Business Server (Dell T-710) mit einer Quad Core CPU einer virtuellen Maschine mehr als etwa 10 GB Arbeitsspeicher zuweisen (ein genauer Grenzwert bei dem der Fehler auftritt ist nicht feststellbar. In unseren Versuchen zwischen 8 und ca. 10,5 GB) bekommt man folgende Fehlermeldung.

Fehler beim Start des Hyper-V Clients

Man schaue sich den Fehlernamen in Verbindung mit der Begründung dazu an. Wir wissen nicht was exakt da schief gelaufen ist, aber wir würden Microsoft davon abraten wollen, sich an der Neudefinition mathematischer Grundrechenarten zu beteiligen. Unseren Kunden würden wir vorerst ans Herz legen keine Microsoft Produkte wie Excel oder dergleichen mehr zu verwenden, denn es kann nicht ausgeschlossen werden, dass die offensichtlich fehlerhafte Berechnungsfunktion auch dort zum Einsatz kommt ‘-)

Wiederholt haben wir in der jüngeren Vergangenheit in Projekten mitgewirkt, in denen unter Verwendung der SCRUM Methodik Software entwickelt wird. Doch was sich erst mal wie eine gute Idee anhört, entpuppt sich vielerorts als ein mehr oder weniger große Farce.

Aus nüchterner Perspektive betrachtet stellt SCRUM den Versuch dar, einige Probleme klassischer Softwareentwicklungmethoden zu lösen. Zum Beispiel wird das Schreiben umfangreicher Spezifikationen zu Gunsten kürzerer Entwicklungszyklen aufgegeben. Kürzere Entwicklungszyklen erzeugen eine besser Sichtbarkeit von Teilergebnissen. Nicht mehr das große Ganze in all seiner Komplexität steht bei SCRUM im Vordergrund, sondern die iterative Erbringung von Kundennutzen. Deshalb ist ein Kunden oder Zwischenkunde auch meistens Teil des SCRUM Teams.

Beschreibung der Methode

SCRUM-Entwicklungsteams haben typischerweise 7-10 Mitglieder von denen ein Teammitglied die Rolle des SCRUM Master und ein weiteres Mitglied die Rolle des Product Owner inne haben. Der SCRUM Master ist als “primus inter pares” zu verstehen. Er steht in keinem hierarchischen Weisungsverhältnis zum Rest des Teams, sondern hat eine Problemlöserfunktion innerhalb des Teams inne. Der Product Owner fungiert in der Role eines fiktiven (oder auch echten) Kunden. Daher wird die SCRUM Methode auch gerne dort genutzt, wo die Entwickler mit den End- oder Zwischenkunden zusammen Software entwickeln sollen und die Erbringung eines Kundennutzen im Vordergrund steht.

Die Entwicklungszyklen in SCRUM heißen Sprints. Sie sind typischerweise 3 Tage bis zu 4 Wochen lang und sind Iterationen an deren Ende eine stabile und funktionsfähige Version des zu entwickelnden Produkts steht. Idealerweise werden die Länge der Sprints und die Inhaber der Rollen zu Beginn eine Projekts festgelegt und während des Projekts nur bei vorliegen zwingender Gründe gewechselt. Ein solcher liegt jedoch NICHT vor, wenn die Sprintziele einmal oder widerholt nicht erreicht worden sind.

Weitere wichtige methodische Elemente von SCRUM sind eine Liste unbedingt umzusetzender Eigenschaften eine Produkts. Diese Liste nennt sich Work Backlog. Zu Beginn eines jeden Sprints gibt es das Sprint Planning. Dieses Meeting dient zunächst dazu die Tasks, die im nächsten Sprint umgesetzt werden sollen, vom Work Backlog auszuwählen und zu bewerten. Die Aufwandsbewertung erfolgt im ganzen SCRUM Team. Danach werden die Tasks vom Product Owner priorisiert. Anschließend werden alle Tasks, die in der insgesamt zur Verfügung stehenden Entwicklungsszeit entwickelt werden können auf die einzelnen Teammitglieder aufgeteilt.

Hierbei ist darauf zu achten, dass alle Teammitglieder eine etwa gleiche Auslastung während des Sprint haben. Jeden Tag findet ein kurzes Meeting im Team statt, an welchem der Product Owner jedoch nicht teilnimmt. Im Rahmen dieses Meetings hat jedes Teammitglied typischerweise 3 Fragen zu beantworten:

1. Was habe ich gestern getan ?
2. Was werde ich heute tun ?
3. Welche Probleme sind aufgetreten / Was hat mich behindert ?

Die Probleme sind im Anschluss an jedes “Daily Scrum” möglichst zeitnah vom SCRUM Master zu beseitigen bzw. abzustellen. Er ist daher gewissermaßen der Winston Wolf des SCRUM Teams und sorgt mit seiner Arbeit dafür, dass das Team möglichst reibungsarm arbeiten kann. Am Ende des Sprints findet das “Review Meeting” statt. In diesem Meeting nimmt der Product Owner wiederum teil und es werden die Arbeitsergebnisse des letzten Sprints besprochen. Typischerweise findet deshalb auch nach dem Review Meeting das “Sprint Planning” für den nächsten Iterationszyklus statt.

Eine der wichtigsten Regeln des Sprint ist, dass as Sprintziel nur dann erreicht ist, wenn ALLE geplanten Arbeitspakete im Rahmen des Sprint abgearbeitet wurden.
Einen Teilerfolg gibt es also bei Anwendung der SCRUM Methode nicht. Dies impliziert, dass ebenfalls bereits zu Projektbeginn eine sehr klare Definition für die Frage, wann etwas wirklich erledigt ist, erfolgen muss. Ken Schwaber, einer der Erfinder von SCRUM nennt dies “The definition of done”. Wer unter den geneigten Lesern dieses Blogs sicht nicht vorstellen kann, dass das Wort “erledigt” verschiedentlich interpretierbar ist, dem seien die drei Youtube Videos vom Ken Schwaber selbst persönlich ans Herz gelegt.

Kritische Diskussion

SCRUM ist eine sehr durchdachte Methode. Mich persönlich fasziniert immer wieder, wie häufig es amerikanischen Wissenschaftlern und Pratikern gelingt, komplexe Sachverhalte in überschaubare Methoden herunterzubrechen. Neben der SCRUM Methode ist zum Beispiel die Portfolioanalyse ein sehr effektive Methode, um komplizierte, multidimensionale Sachverhalte in einfache, nachvollziehbare Visualisierungen zu transformieren. SCRUM führt jedoch nicht ohne Einsatz zu guten oder besseren Ergebnissen als die klassischen Entwicklungsmethoden wie z.B. Wasserfall oder das V-Modell.

Eine akribische Beachtung der methodischen Grundsätze (Daily Scrum, Scrum Review Meeting), Einhaltung der Rollenzuordnungen (SCRUM Master, Product Owner) und eine klare a-priori Festlegung der “definition of done” sind wesentliche Grundsätze der Methode, die gelebt und verstanden werden müssen. Zwar setzt SCRUM Agilität durch kleine, überschaubare Teams, kürzere Entwicklungszyklen und Kundenpartizipation methodisch um, ob am Ende aber eine gutes und für das Team und den Kunden zufriedenstellendes Ergebnis steht, hängt wesentlich von der Einhaltung des Methodenfundaments ab. Jede Abweichung von der radikalen Vereinfachung des Entwicklungsprozesses nach SCRUM birgt die Gefahr am Ende mit schlechteren und vor allem teureren Ergebnissen konfrontiert zu werden, als sie klassische Methoden hervorgebracht hätten.

Auch wenn SCRUM das Lernen und Problemlösen im Team und damit das Gruppenziel in den Vordergrund stellt, ist es absolut notwendig ein SCRUM Team so zu besetzen, dass die Chance des Niveausausgleichs grudsätzlich gegeben ist bzw. das notwendige Spezialkenntnisse durch entsprechende Kompetenzträger abgedeckt werden. Teammitglieder die nachhaltig die Schätzwerte hinsichtlich des Zeitaufwandes für die Ihnen zugeteilten Aufgaben überreizen sind langfristig demotivierend und eine Belastung für den Rest des Teams sowie eine Gefahr für den Projekterfolg. SCRUM nur als Modewort zu verstehen und zu einer leeren Hülle verkommen zu lassen, weil die grundlegenden Regeln keine Beachtung mehr finden, ist jedenfalls keine gute Idee.

Dabei ist klar an sich sonnenklar, Software, die wir durch unsere Steuergelder bezahlt haben, sollten wir auch nutzen können. Auch sollten wir nicht für das selbe Problem nochmal die Entwicklung bezahlen, nur weil die Software von einer anderen Behörde oder öffentlichen Einrichtung genutzt wird. Open Source Software ist unseres Erachtens nicht nur der beste, sondern sogar der einzige Lösungsweg.

Wo wir mit der NASA schon bei der Luft- und Raumfahrt waren, können wir zeigen, das sich dort langsam aber sicher auch etwas bei uns bewegt. Sicherlich ist das nicht das erste Open Source Projekt, aber der Mitarbeiter Roland Winkler vom Institut für Flugführung beim DLR Deutsches Zentrum für Luft- und Raumfahrt e.V. hat seine DataMining Java Library unter einer BSD Lizenz auf Github veröffentlicht.

Auch wenn das DLR selbst nicht zu unseren Kunden zählt, konnten wir im vorliegenden Fall Herrn Winkler -hoffentlich wertvolle- Tipps geben, wie man eine geeignete Open-Source-Lizenz auswählt und welche Rahmenbedingungen dabei zu beachten sind. Des weiteren  konnten wir ihn über die Möglichkeiten und Risiken einer umfassenden Open-Source-Strategie beraten. Wir teilen gerne unser Wissen über Open-Source-Strategien. Wenn Sie also wissen wollen, wie Sie ihr Softwareprodukt mit einer Open-Source Strategie erfolgreich machen, melden Sie sich einfach bei uns.

“Wie kann man in einem TYPO3 Fluid Template die Inhalte sauber darstellen, die folgende Anforderungen erfüllen ?”.

Im Extbase basierten Backend soll es Multiple Checkboxen geben, die auf ein Integer gemapped werden. In unserem Fall sind dies z.B. Organisationseinheiten.

In der TCA von TYPO3 lässt sich das mit ‘type’ = ‘check’ umsetzen, doch wie ließt man selbiges wieder aus, wenn die Anwendungslogik von TYPO3 meint, es in einer Binärdarstellung in der Datenbank halten zu müssen ?

Nach einem Tipp für die richtige PHP-Funktion, haben wir einen kleinen ViewHelper gebaut. Den Code wollen wir euch nicht vorenthalten.

Vielleicht kann ihn der eine oder andere in seinen Projekten auch gebrauchen.

class Tx_Initos_ViewHelpers_CheckViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
        /**
         * ViewHelper to get state of check
         * @param int $int
         * @param int $pos
         */
  public function render($int = 0, $pos = 0) {
    $s = decbin($int);
    if(strlen($s) > ($pos+1))
      return false;
    return substr($s, -($pos+1), 1);
  }
}

Im Fluid Template kann man dies dann mit der folgenden Inline-Syntax abfragen:

{namespace initos = Tx_Initos_ViewHelpers}
<f:if condition="{initos:check(int: '{person.position}', pos: '{type}')}">
<f:then>
	Checkbox 1 gesetzt
</f:then>
</f:if>

Die ViewHelper in Fluid sind das Schweizer Taschenmesser, um erfolgreich und effizient das passende Template für die Extbase Extention von TYPO3 zu bauen.

Wir werden deshalb gerne unser Wissen teilen und stehen für Fragen natürlich wie immer gerne zur Verfügung.

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.

Einer unserer Kunden kam mit dem Wunsch auf uns zu, seinen Magentoshop zu beschleunigen. Es ist ein relativ neuer Shop, der noch am Anfang seiner Entwicklung steht. Das Hosting übernimmt ein vServer, für den der Kunde auch root-Zugang hat. Unsere ersten Schritte bestanden in einer Ist-Analyse gefolgt von einer Soll-Definition. Der Kunde wählte dafür eine für Ihn repräsentative Seite aus.

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”