Performance Test - CMSMS schneller als Typo3

czarnowski · 19. März 2013 14:49

Ausgehend von dem Aufruf von Cyberman mal ein paar Daten zur Performance bereit zu stellen arbeite ich nacheinander ein paar Titel ab.

Die Titel werden richtig heftig belastet.

Hier schon mal ein Auszug mit der klaren Aussage CMSMS hat gegenüber Typo3 unter richtigem Stress klare Performance Vorteile.
Allerdings darf die Freude verhalten sein denn auch die Leistung von CMSMS ist für eine harte Belastung nicht ausreichend.

Hier ein Image dazu.

Test1

czarnowski · 19. März 2013 17:47

Bislang schneidet Wordpress am miesesten ab ist praktisch bei kleinen Besuchszahlen nicht mehr verwendbar.
Hier würde ich auf jeden Fall die Finger davon lassen, wenn es um gewerbliche Projekte gehen sollte.

Starke Verbreitung ist eben nicht die Garantie für gute Leistung.

Das zweitbeste Ergebnis liefert Drupal ab.

Alle Test's wurden auf einem lokalen Hochleistungsserver gemacht.
32 GB RAM / Mysql / PHP und System auf SSD Platte, Webverzeichnis auf SATA 9 Highspeed Platte.

Renderzeiten, DNS Zeiten und ähnliches spielen bei diesem Test absolut keine Rolle.

Zeiten um die 1000 ms als response sind daher definitiv nicht ausreichend für Sites mit guten Besucherzahlen.

Weitere Test's werden nächste Woche erfolgen.

czarnowski · 19. März 2013 18:13

E107 hat ebenfalls hervorragende Leistungswerte und ist auch für ganz dicke Besuchermengen geeignet.

Janl · 19. März 2013 18:25

Danke Czarnowski,

es bestätigt meine Erfahrungen mit Wordpress.
Kurzher eine WP-Seite mal detailliert angesehen, da war 96,5% Kode und nur 6,5% Text, dann wird es langsam.

Deine Grafik ist sehr hilfreich!

mfg
Jan

faglork · 19. März 2013 19:06

czarnowski schrieb:

Bislang schneidet Wordpress am miesesten ab ist praktisch bei kleinen Besuchszahlen nicht mehr verwendbar.
Hier würde ich auf jeden Fall die Finger davon lassen, wenn es um gewerbliche Projekte gehen sollte.

http://social.ford.com/
http://blogs.wsj.com/law/
http://blog.us.playstation.com/
http://business.blogs.cnn.com/
http://product.espn.com/
http://blogs.reuters.com/us/
...

Lauter Fehlentscheidungen ...?

http://wp.smashingmagazine.com/2012/09/ … ess-blogs/

Servus,
Alex

czarnowski · 19. März 2013 20:37

Es ist grundsätzlich eine Fehlentscheidung Wordpress zu wählen wenn man eine Site gewerblich nutzen will.
Die von jedermann messbaren Leistungen sorgen dafür das extrem frühzeitig eine Wachstumsgrenze eintreten wird.

Es ist sinnlos eine Zahl von WP Sites aufzuzählen die gibt es in Massen.
Wer ein Problem hat das zu verstehen sollte mal selbst den AB auf seinem Server oder Xampp testen - er wird sich die Augen reiben.

Und nochmals Renderzeiten, DNS Zeiten und ähnliches spielen bei diesem Test absolut keine Rolle.
Die kommen noch hinzu wenn man übers Netz testet - es wird im Netz also langsamer werden und das bei allen !

-------------------------
Um mal zu zeigen was möglich ist habe ich auch mal mein eigenes High Speed Framework MinMalist eingebunden (keine OS).
Das ist aber kaum zu sehen da dieses in den Bereichen um die 40 ms abliefert - das sind so die tatsächlich erreichbaren unteren Grenzen.

nhaack · 19. März 2013 20:50

Aber gäbe es nicht die Möglichkeit mit Caching entweder im CMS oder dem Webserver/Server (z.B. MemCache) den Leistunsgeinbußen entgegenzuwirken?

Klar, im Grundsetup haben alle Systeme Ihre Falschenhälse, aber wer eine Site gewerblich aufsetzt, dürfte sich diesem Thema doch auch widmen.

Mich würde mal interessieren, was bei den Systemen die Flaschenhälse sind. Ist es tendenziell eher der PHP Code oder sind es die Datenbank Queries? Kannst du dazu was sagen?

Viele Grüße
Nils

nockenfell · 19. März 2013 20:54

Interessant wäre bei WP die Auswirkung von Cache-Plugins wie WP-Supercache und Konsorten

Das selbe gilt für CMSMS mit der Erweiterung von kermit

czarnowski · 19. März 2013 21:21

nockenfell schrieb:

Interessant wäre bei WP die Auswirkung von Cache-Plugins wie WP-Supercache und Konsorten

Sondersachen werden nicht geprüft - der Aufwand wäre viel zu hoch - da müsste man bei allen Titeln schauen was die diesbezüglich im Angebot haben und alles nötige gegebenenfalls installieren und einrichten.

Wer dazu näheres wissen will der muss selbst testen.

Allerdings halte ich das für relativ uninteressant wenn der Standard bereits schlechte Leistung bringt.
Spezielle Cachemethoden etc. würden alle Titel verbessern, wenn vorhanden.

Bestimmte Methoden bedingen besondere Fähigleiten des Servers selbst z.B. Memcache = Dienst auf dem Server - wie auch programmtechnische Unterstützung.
Memcache bringt etwas - wenn man es mit der AB Methode checkt - der Einzelaufruf einer Seite mit Memcache als Messlatte bringt dagegen rein nichts.

Wo die Flaschenhälse stecken muss man im Einzelfall untersuchen.
In der Regel ist das fast immer ein ganzes Bündel von Fehlentscheidungen beim Systementwurf und selten Einzeldinge a la rauchender Colt.

Noch ergänzend:

Getestet wird unter aktuellen also die z.Z. verfügbare stabe Versionen von Apache,PHP und Mysql.
Es sind nur Titel enthalten die sich darunter installieren lassen und die beim Benchmark 0 Fehler abliefern.

Es gibt eine ganze Reihe von Titeln die da durchfallen.

Beim Test gibt es 100 virtuelle User die konkurrierend 50.000 Zugriffe ausführen.

Beitrag geändert von czarnowski (19. März 2013 21:27)

czarnowski · 20. März 2013 17:18

Den Test habe ich beendet.
Zahlreiche Titel die ich noch gerne getestet hätte konnte man nicht unter den aktuellen Versionen installieren.

Das Bildformat habe ich vergrößert um einfach besser lesen zu können.

Nochmals zur Erinnerung - die Leistungen aller Titel dürften wenn man sie im Netz direkt machen würden deutlich schlechter ausfallen.
Und eine solche Ausstattung wie der Testserver bei mir dürfte als Webserver um die 300..400 € / Monat kosten - so etwas haben nur ganz wenige zur Verfügung.

Es gibt Titel bzw. Siteangebote die leisten dann noch nicht einmal 3 Request's pro Sekunde und das bei nur -n 100 -c 100

Mein Fazit

Es gibt als kostenlose Software nur ganz wenige Titel bei denen man nicht befürchten muss das man Besucher allein dadurch nicht bekommt weil man sie nicht bedienen kann.
Die meisten Titel sind die reinsten Wachstumsbremsen - sie erscheinen nur brauchbar bei wirklich sehr geringer Belastung - im Bild praktisch daran zu erkennen wo links der Knick nach oben abgeht.

Was hier nicht zu erkennen ist - die ganz miesen Titel benötigten über 30 Minuten um 50.000 Request's bedienen zu können, die besten Titel gerade mal 19 Sekunden.

Eines der Hauptprobleme scheint der teils dramatische Einsatz von OOP mit teils "endlosen" Erweiterungen einer Basisklasse und die Unfähigkeit der Programmierer die Referenzen zu nicht mehr benötigte Variablen über ein einfaches unset zu killen - das aber hat zur Folge das eine Freigabe des RAM's über die garbage collection Methoden von PHP während eines Laufes nicht mehr erfolgt und wegen Hochlast auch nicht ausreichend erfolgen wird.
Deswegen - kann man rechts sehen wo es steil nach oben geht - der stetige und dann radikale Anstieg der Zeiten, der anzeigt das auch ein 32 GB Server für diese Titel nicht mehr ausreicht.

Ganz sicher gibt es auch konzeptionelle Dinge aber dazu müsste man in's Detail gehen, das aber ist hier nicht Gegenstand der Untersuchung.

Man sollte nicht überrascht sein das ausgerechnet die Titel von denen man in Fachkreisen am meisten redet die richtigen Spassbremsen sind und geschäftlich betrachtet echte Geschäftskiller sind.

Ein einzelner Seitenaufruf mit dem Ergebnis - ist ja schnell - ist völlig uninteressant.
Eine Site will normalerweise viele Besucher haben und je mehr desto besser.

Aber nur wenige machen sich Gedanken ob seine Kombination bestehen aus Hardware, System, Apache,PHP und Mysql wie natürlich im echten Netzbetrieb alle Methoden nach Pagespeed ausreichend sind um ein Wachstum leisten zu können.

Wenn man diverse Titel unter gleichen Bedingungen so testet fehlen natürlich die Bremsen die das Netz selbst hat wie auch Pagespeeddinge und Rendering - man kann aber sehr schnell beurteilen was ein Titel diesbezüglich taugt.

faglork · 20. März 2013 18:53

czarnowski schrieb:

Es ist sinnlos eine Zahl von WP Sites aufzuzählen die gibt es in Massen.

Quatsch. Das sind High-Traffic-Sites, und zwar reale.

Wenn du dir den Artikel dazu durchliest, dann siehst du auch wie die das Problem angegangen sind.

Und was die Relevanz des ganzen angeht: kann mal bitte jemand die Hand heben der eine Site betriebt die auch nur annähernd in die oberen Regionen dieses "Tests" kommt?

Ich behaupte mal einfach: für 99% der Websites die hier in diesem Forum betreut werden spielt das überhaupt keine Rolle.

Servus,
Alex

faglork · 20. März 2013 18:56

Janl schrieb:

Danke Czarnowski,
es bestätigt meine Erfahrungen mit Wordpress.

Du hast Websites mit 40-50k Anfragen pro Sekunde?
Gib mal ne URL ...

Servus,
Alex

czarnowski · 20. März 2013 20:51

Es ist wie immer das Problem das Leute sich nicht mit dem beschäftigen um was es geht aber mit reden ohne Ende.
-c 100 bedeutet - 100 simulierte User die gleichzeitig auf ein Web zu greifen und dabei
-n 50000 Aufrufe machen - also 50.000 und nicht 50.000 x 100 .

Wir haben also in der Zeitreihe 50.000 Messpunkte

Und - wer mal lesen würde - hier wird lokal getestet - ein solcher Test auf einen Livebetrieb würde bedeuten das man damit die schwache Website in Nullkommanix lahm legt oder man von der Firewall raus geworfen wird.

Ein Tag hat 86400 Sekunden - hat man pro Sekunde einen Besucher hat man sicher eine High Traffic Site - das ist hier überhaupt nicht das Thema.

Hat man aber eine Anzahl von Besuchern die gleichzeitig wursteln dann sieht es völlig anders aus.

Habe da mal 2 deiner Links mit wesentlich kleinerm Aufkommen live testen können:

Von Speed kann man da nicht reden insbesondere weil da auch noch die Browserzeiten fehlen.

Die Regeln sind immer gleich

Ab 1 Sekunde Komplettzeit fangen Besucher an ab zu hauen , es sei denn man ist auf den Inhalt einer Seite angewiesen.
Ja sie brechen laut Amazon sogar angefangene Bestellungen ab.
Da gibt es viele Quellen dazu.

Und ja - es gibt Systeme die schaffen den Test in 19 Sekunden.

Andynium · 20. März 2013 21:31

Mir fehlt der Test von Contao noch in deiner Liste wink ...

czarnowski · 20. März 2013 22:45

cyberman schrieb:

Mir fehlt der Test von Contao noch in deiner Liste

Auf besonderen Wunsch eines Sachsens .......

Mal als kleiner Hinweis - bei den Kauf - Systemen sieht es besser aus.
Von 9 Systemen können 4 mit den besten Werten sehr gut mit halten.

Da habe ich auch noch umfangreichere Analysen - die kann ich aber nicht veröffentlichen, da Auftragsarbeit.
So etwas wird übrigens auch hervorragend bezahlt - da es da insgesamt für den Auftraggeber um ziemlich hohe Gesamtsummen für Lizenzen geht.
Man möchte da einfach kein Geld für Schrott zum Fenster werfen.

Es gibt bezüglich der Qualität schon erhebliche Unterschiede in der Programmierung zu OS Systemen.

faglork · 20. März 2013 22:46

czarnowski schrieb:

Es ist wie immer das Problem das Leute sich nicht mit dem beschäftigen um was es geht aber mit reden ohne Ende.
-c 100 bedeutet - 100 simulierte User die gleichzeitig auf ein Web zu greifen und dabei
-n 50000 Aufrufe machen - also 50.000 und nicht 50.000 x 100 .

Sagte ich doch: 50k ...

czarnowski schrieb:

Ein Tag hat 86400 Sekunden - hat man pro Sekunde einen Besucher hat man sicher eine High Traffic Site - das ist hier überhaupt nicht das Thema.
Hat man aber eine Anzahl von Besuchern die gleichzeitig wursteln dann sieht es völlig anders aus.

Na dann doch mal Butter bei die Fische. Aufruf an das Forum: Wieviel Besucher hat denn eure meistbesuchte Seite?
Ich oute mich mal: Meine meistbesuchte Seite hat grad mal 4k Besucher verteilt über den Tag.

Wer bietet mehr? Ich bin gespannt.

Deine Studie ist sicher aufschlussreich, aber Aussagen wie "Bislang schneidet Wordpress am miesesten ab ist praktisch bei kleinen Besuchszahlen nicht mehr verwendbar. Hier würde ich auf jeden Fall die Finger davon lassen, wenn es um gewerbliche Projekte gehen sollte." sind doch voll daneben. Die Realität sieht halt anders aus.

Servus,
Alex

czarnowski · 20. März 2013 22:50

Sagte ich doch: 50k ...

50k / 100, denn es werden 100 parallel abgefeuert.

Die Realität sieht halt anders aus.

Ganz einfach - die Anwender machen sich schnell eine Seite und haben von den Hintergründen keine Ahnung - so wie du nun wahrscheinlich zum ersten Mal damit konfrontiert wurdest.

Schau einfach mal ganz links unten nach ab welchen Mickerzugriffszahlen die Systeme bereits einknicken.

Was meinst du warum der Ab

a. von Apache entwickelt wurde
b. von Administratoren auch eingesetzt wird

bestimmt nicht weil sie gelangweilt auf den Frühling warten

Beitrag geändert von czarnowski (20. März 2013 22:52)

faglork · 21. März 2013 23:53

czarnowski schrieb:

Ganz einfach - die Anwender machen sich schnell eine Seite und haben von den Hintergründen keine Ahnung - so wie du nun wahrscheinlich zum ersten Mal damit konfrontiert wurdest.
Schau einfach mal ganz links unten nach ab welchen Mickerzugriffszahlen die Systeme bereits einknicken.

Ja, das wirds wohl sein ...

http://www.digitaltrends.com/
ist eine WP Seite mit 30 Millionen Pageviews im Monat. Die Seite stammt von
http://hmn.md/
"die Anwender machen sich schnell eine Seite und haben von den Hintergründen keine Ahnung "
Jaja. Das wirds wohl sein. Und auch deren Kunden sind doof.

Geh einfach mal auf die Seite http://www.digitaltrends.com. Schau dich mal ein bisschen dort um. Und beobachte wie die Seite "einbricht".

czarnowski, wenn meine Seite mal 30 Millionen Pageviews/Monat hat und dann anfängt so krass einzubrechen wie digitaltrends.com, DANN mach ich mir auch Gedanken.
Derzeit sind es ca. 120.000 Pageviews/Monat. Nuja. Dauert wohl noch ein bisschen.

Bis dorthin ...
Alex

Beitrag geändert von faglork (21. März 2013 00:05)

czarnowski · 21. März 2013 14:11

Also mein lieber faglork du verstehst vom Test und Benchmark rein nichts.
Auch deine krampfhaften Bemühungen zur Argumentation über real existierende Sites sind komplett für die Katz.

Ob nun digitalttrends oder eine andere Site x Mio Seitenaufrufe hat oder nicht ist völlig egal.

Es ist genauso völlig egal ob andere nur 3000 Seitenaufrufe im Monat haben.

Was man bei Live - Sites nicht sehen kann welche Maßnahmen da getroffen wurden um erträgliche Geschwindigkeiten zu erzielen.

Was man allerdings sehen kann - da werden Inhalte bei digitaltrends über mehrere CDN Verbindungen geliefert.
Ob und welche besonderen Maßnahmen zusätzlich ergriffen wurden kann man nicht erkennen.
Allein die CDN Aufbereitung dürfte denen jede Menge Geld / Monat kosten.
Ganz sicher wird hier auch Geld dafür ausgegeben um die mangelnde Leistung des Systems irgendwie auszugleichen.

Und dennoch ist die Site real langsam- liegt so um die 2,8 Sekunden.

Warum sind denn nun deine Links völlig egal ?

Ganz einfach weil sie für die Betrachtung unwichtig sind.

Man nehme einen dicken lokalen Server, installiere die Anwendung X und ruft sie exklusiv auf und belastet diese Anwendung mit einer Menge die ausreicht um das ganze bis an die Grenzen zu belasten.

Die Werte speichert man.

Dann nehme man andere Titel und verfahre genau so.

Am Ende macht man einen Plot mit allen getesteten Daten und Titeln und hat einen Vergleich.

Da sich am Server und an der Testmethode nichts geändert hat kommen Differenzen zwischen den Titeln aus den Titeln selbst.

Damit wird ein grundsätzlicher Vergleich möglich aber auch eine Aussage das Titel a oder b eben die miesesten Werte liefern.

Und - hier speziell mal wieder - es gibt Leute die beteiligen sich wie wild und geben sich keine Mühe a. zu lesen und b. sich damit zu beschäftigen.

Es gibt ja nicht umsonst eine x y Einteilung.
Und wie man (siehe Bild) ganz klar erkennen kann, steigt response time bereits bei sehr wenigen Request's ziemlich steil an - zumindest bei den meisten und das bei nur 100 virtuellen Usern.

Deswegen ist ein Gejammer nach dem Motto wer hat denn schon so viele Besucher hier von uns völlig überflüssig.

Was man auch sehr gut erkennen kann - so manche Titel haben dicke Probleme mit der Freigabe nicht mehr benötigten RAM's, deswegen steigen die Zeiten ziemlich an und ab einer Größenordnung Z sogar radikal.
Das sind ganz klar Programmierschlampereien und ein ziemlich mieser Code.

Auf der anderen Seite - da wiederhole ich mich und nun noch klarer:

Server mit weniger Leistung (egal ob CPU, RAM oder Festplatte) erzeugen teils drastisch weniger Leistungen
shared Webserver haben den Nachteil das man die Belastung des Servers durch andere weder kennt noch vorhersehen kann - die Leistungen dürften auf diesen Servern radikal geringer sein

Auf einem Live Server spielen noch andere Dinge eine Rolle wie Netzanbindung etc .
Tatsächlich kann ein Live Test mehrfach schlechtere Zeiten ergeben.

Die Realzeit - also über einen Browser - wird ebenfalls eine andere nämlich wesentlich höhere sein.

Unterm Strich kann man bei einem solchen Test eines sehen:

Wer mit seiner Domain eine hohe und vor allem wachsende Besucherzahl bedienen möchte der ist sehr schlecht beraten einen Titel auszuwählen der bei dem Test schlecht abgeschnitten hat.

Es gibt eben eine technisch (Server, System und Programmierung des Web's) gegebene Begrenzung die bei manchen Titeln sehr früh und ziemlich hart einsetzt.

Und es gibt immer noch die berühmte 1 Sekunden Grenze die man möglichst einhalten oder unterschreiten sollte - die gilt allerdings für eine fertig gerenderte Seite.

czarnowski · 21. März 2013 14:28

Ich möchte noch schnell das Stichwort memcache aufgreifen.

Memcache kann man natürlich auf dem Server installieren auf dem das Web liegt.

Das aber reduziert auch das zur Verfügung stehende RAM und erhöht die CPU Last da Memcache als Dienst läuft.

Sinnvollerweise nutzt man Memcache über extra Server mit viel RAM - große Websites haben da eine ganze Kette von laufen.

Memcache muss aber auch von der Applikation unterstützt werden.

Sind mehrere Memcache-Server am laufen muss die Applikation auch das unterstützen.

Memcache selbst bringt bei einzelnen Seitenaufrufen nichts kann sogar langsamer sein als ohne.

Memcache bringt jedoch bei echter Belastung eine ganze Menge und erhebliche Entlastung.

Andynium · 22. März 2013 05:57

czarnowski schrieb:

cyberman schrieb:
Mir fehlt der Test von Contao noch in deiner Liste
Auf besonderen Wunsch eines Sachsens .......

Besten Dank!!

Gibts den Plot auch 'ne Nummer größer? Hab beim Betrachten das dringende Gefühl, meinen Optiker aufzusuchen ... kannst die Datei auch hier hochladen.

Cherry · 22. März 2013 10:04

cyberman schrieb:

Gibts den Plot auch 'ne Nummer größer?

ich klick bei solchen Grafiken immer per Rechtsklick drauf. Im Kontextmenü gibts dann 'Grafik anzeigen' womit die Grafik im neuen Fenster dargestellt wird (FF) und sich nun beliebig vergrößern läßt. Eigentlich ist die ja wirklich groß.

Andynium · 22. März 2013 13:40

Cherry schrieb:

ich klick bei solchen Grafiken immer per Rechtsklick drauf. Im Kontextmenü gibts dann 'Grafik anzeigen' womit die Grafik im neuen Fenster dargestellt wird (FF) und sich nun beliebig vergrößern läßt. Eigentlich ist die ja wirklich groß.

Danke für den Trick - da ich immer auf die finale Auflösung skaliere, bin ich auf so etwas simples noch nicht gekommen glasses .

Muss hier doch mal irgend wie 'ne Fancy-Box einbauen ...

Cherry · 22. März 2013 15:31

cyberman schrieb:

Muss hier doch mal irgend wie 'ne Fancy-Box einbauen ...

Das wäre cool..

czarnowski · 22. März 2013 20:59

Um mal zu zeigen wie eine Live Site reagiert habe ich mal ausnahmsweise eine hier bekannte Site gecheckt und zwar mit einer sehr kleinen Last um den Zielserver nicht zu überlasten.

Ich habe übrigens einen echte 100 MBit Zugang.

Das Ergebnis sieht so aus:

ab -n10 -c10 http://www.festtagsgedichte.de/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.festtagsgedichte.de (be patient).....done

Server Software: Apache
Server Hostname: www.festtagsgedichte.de
Server Port: 80

Document Path: /
Document Length: 45833 bytes

Concurrency Level: 10
Time taken for tests: 4.060 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 461630 bytes
HTML transferred: 458330 bytes
Requests per second: 2.46 [#/sec] (mean)
Time per request: 4060.198 [ms] (mean)
Time per request: 406.020 [ms] (mean, across all concurrent requests)
Transfer rate: 111.03 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 24 32 5.4 29 39
Processing: 2539 3204 432.8 3196 4031
Waiting: 2437 3115 439.1 3102 3946
Total: 2568 3236 433.9 3225 4060

Percentage of the requests served within a certain time (ms)
50% 3225
66% 3302
75% 3429
80% 3757
90% 4060
95% 4060
98% 4060
99% 4060
100% 4060 (longest request)

Es soll lediglich dokumentieren das die reale Leistung sehr viel geringer ist als die in dem großen Test.
Wir haben lediglich 10 virtuelle User mit insgesamt 10 Aufrufen - das ist also eine wirklich geringe Menge.

Es zeigt deutlich das diese Website kaum Chancen haben wird zu wachsen da hier die Begrenzung zu massiv ist.
Die Begrenzung macht jede Anstrengung im Bereich Inhalt und Darstellung völlig kaputt.

Also denkt daran Live sehen die Ergebnisse wirklich vollkommen anders aus, da hier auch die ganzen Netzanbindungen eine Rolle spielen - allerdings das Rendering nicht.

Forum für CMS/made simple

#1 19. März 2013 14:49

Performance Test - CMSMS schneller als Typo3

#2 19. März 2013 17:47

Re: Performance Test - CMSMS schneller als Typo3

#3 19. März 2013 18:13

Re: Performance Test - CMSMS schneller als Typo3

#4 19. März 2013 18:25

Re: Performance Test - CMSMS schneller als Typo3

#5 19. März 2013 19:06

Re: Performance Test - CMSMS schneller als Typo3

#6 19. März 2013 20:37

Re: Performance Test - CMSMS schneller als Typo3

#7 19. März 2013 20:50

Re: Performance Test - CMSMS schneller als Typo3

#8 19. März 2013 20:54

Re: Performance Test - CMSMS schneller als Typo3

#9 19. März 2013 21:21

Re: Performance Test - CMSMS schneller als Typo3

#10 20. März 2013 17:18

Re: Performance Test - CMSMS schneller als Typo3

#11 20. März 2013 18:53

Re: Performance Test - CMSMS schneller als Typo3

#12 20. März 2013 18:56

Re: Performance Test - CMSMS schneller als Typo3

#13 20. März 2013 20:51

Re: Performance Test - CMSMS schneller als Typo3

#14 20. März 2013 21:31

Re: Performance Test - CMSMS schneller als Typo3

#15 20. März 2013 22:45

Re: Performance Test - CMSMS schneller als Typo3

#16 20. März 2013 22:46

Re: Performance Test - CMSMS schneller als Typo3

#17 20. März 2013 22:50

Re: Performance Test - CMSMS schneller als Typo3

#18 21. März 2013 23:53

Re: Performance Test - CMSMS schneller als Typo3

#19 21. März 2013 14:11

Re: Performance Test - CMSMS schneller als Typo3

#20 21. März 2013 14:28

Re: Performance Test - CMSMS schneller als Typo3

#21 22. März 2013 05:57

Re: Performance Test - CMSMS schneller als Typo3

#22 22. März 2013 10:04

Re: Performance Test - CMSMS schneller als Typo3

#23 22. März 2013 13:40

Re: Performance Test - CMSMS schneller als Typo3

#24 22. März 2013 15:31

Re: Performance Test - CMSMS schneller als Typo3

#25 22. März 2013 20:59

Re: Performance Test - CMSMS schneller als Typo3

Fußzeile des Forums