Ganzseitiger Cache unter CE 1.8 - Ein FPC-Magento-Modul? Lack? Beide?

15

Ich bin also ein bisschen verwirrt, wenn ich mich mit der Untersuchung von Full Page Caching für Community Edition 1.8 befasse. Ich habe bereits einen Two-Level-Redis-Cache (CDN) implementiert, die my.cnf von MySQL auf maximale Leistung optimiert (wobei sich die DB natürlich auf einem separaten Server befindet), und ich habe 2 Server, die unseren Shop hinter einem Load Balancer hosten. Ich sage dies, um darauf hinzuweisen, dass ich nicht sofort zur FPC springen werde, bevor ich die anfänglichen Leistungsverbesserungen vornehme.

Ich habe Varnish noch nie auf einer Website verwendet, geschweige denn in Magento, und ich habe auch noch nie eine FPC in Magento eingerichtet. Ich verstehe Varnish als einen Proxy, der als Kreuzung zwischen einem CDN und einem eigenen Seiten-Cache fungiert und Daten an den Browser sendet, bevor die Anfrage überhaupt an den Webserver gelangt. Und meines Erachtens erstellt ein FPC-Modul lokal einen Cache, den der Webserver selbst ausgibt. Ich weiß, dass Sie für beide Setups einige "Hole Punching" -Vorgänge durchführen müssen, um den dynamischen Inhalt in den Browser zu übertragen (obwohl die Techniken zwischen der Verwendung eines Moduls oder der Verwendung von Varnish unterschiedlich sind). Bitte korrigieren Sie mich, wenn ich hier etwas missverstehe.

Bis jetzt habe ich sie als zwei separate Entitäten betrachtet, die Sie implementieren könnten, um Ihrer Site zu helfen, aber jetzt scheint etwas, das ich gelesen habe, das Gegenteil zu implizieren. Mein ursprünglicher Plan war es, das Modul " Warp Advanced Full Page Cache " für Magento (ehemals "Tiny Brick Lightspeed FPC", glaube ich) zu kaufen , da es am beliebtesten zu sein scheint, wenn auch etwas teurer (aber ehrlich gesagt) 350 US-Dollar sind nicht viel für unser Unternehmen, vor allem nicht für das, was es leisten kann. Ich selbst und zwei meiner Mitentwickler wollten lernen, wie man es richtig und vollständig in unser eigenes, selbstgemachtes Thema umsetzt, um das zu maximieren, was wir daraus machen können. Nachdem dies erledigt war, überlegte ich mir irgendwann, ob ich auch die Implementierung von Varnish in Betracht ziehen würde - aber wie ich bereits sagte, hatte ich verstanden, dass sie getrennt waren.

Jetzt stoße ich jedoch auf Erweiterungen wie diesen PageCache Powered by Varnish, der kostenlos ist, oder diesen Vortex Cache Powered by Varnish Cache, der fast 800 USD kostet. Dies sind Magento-Ganzseiten-Cache-Module, die direkt mit Varnish zusammenarbeiten.

Meine Frage an Sie, Stapelaustausch, ist, wie soll ich einen FPC und einen Lack sehen? Als getrennte Einheiten? Wenn ja, schließen sie sich gegenseitig aus? Sind das zwei Seiten einer Medaille, die ich gemeinsam umsetzen sollte? Oder sind sie ähnlich, aber weder exklusiv noch inklusiv?

Kann ich die oben erwähnte Warp Advanced FPC mit Varnish verwenden? Soll ich es mit Lack verwenden? Oder wäre es besser, eine andere FPC zu verwenden, wenn ich Lack verwenden möchte? ODER noch weiter, gibt es eine FPC, die so gut ist, dass ich keinen Lack benötige? Oder umgekehrt, sollte ich einfach Lack verwenden und die FPC-Idee fallen lassen?

Es tut mir leid für die Textwand, aber ich habe viele Artikel, Blogs und Forenbeiträge gelesen und konnte keine endgültige Antwort auf diese Fragen finden. Ich schätze deine Hilfe und deinen Input in dieser Angelegenheit sehr =)

Oh und zum Schluss noch eine kurze Frage zu Varnish und Webservern. Derzeit verwende ich das normale Apache LAMP-Stack-Setup, aber seit einiger Zeit schwärmen die Leute von der Verwendung von Nginx mit Magento. Ich habe einige Tests selbst durchgeführt, Stresstests und Belastungstests, und es scheint, dass es unter den richtigen Bedingungen definitiv ein bisschen besser funktionieren kann. Aus diesem Grund habe ich in naher Zukunft über einen Wechsel nachgedacht. Würde dies meinen Wunsch und meine Entscheidung, eine FPC und / oder einen Lack zu verwenden, irgendwie beeinträchtigen?

Vielen Dank!!!

EDIT: Oh! Und noch eine kurze Frage: Da sich hinter einem Load Balancer zwei Server befinden, auf denen meine Site gehostet wird (dies ist auch eine Einrichtung, die bei Bedarf horizontal erweitert werden kann), nutze ich Redis und Memcached, die auf einem anderen Server als dem gehosteten Server ausgeführt werden Web- und DB-Versionen für meine Sessions und jede Ebene des Two Level Cache von Magento (Zend). Ich nehme an, der FPC würde seine Daten in einem dieser Systeme speichern. Benötige ich eine bestimmte Erweiterung, um sie dort zu speichern, oder machen das alle? Und obwohl ich nicht davon ausgehe, würde dies Varnish in irgendeiner Weise beeinträchtigen? Danke noch einmal!!

ThatSourDiesel
quelle
Anscheinend kann ich aufgrund meines schlechten Rufs nur zwei Links in meine Textwand einfügen. Was für eine Art , mich zu ermutigen , für den Internet - Punkte zu gehen Troll ... sagte, hier sind die Links: Vortex Cache angetrieben durch Varnish Cache aaand Pagecache angetrieben durch Varnish
ThatSourDiesel
3
Ich kann nicht viele Ratschläge zu Varnish geben, aber ich empfehle, einen Blick auf Lesti FPC zu werfen - gordonlesti.com/lestifpc Es ist völlig kostenlos, hat Lochen und kann über den Administrator konfiguriert werden. Es ist absolut genial.
Paul
@ThatSourDiesel - können Sie uns sagen, was Sie getan haben? Am besten unter der akzeptierten Antwort, wenn Sie diese zumindest für Ihre Lösung verwendet haben.
SPRBRN

Antworten:

28

In der Informatik gibt es zwei schwierige Dinge:

  1. Dinge benennen
  2. Cache-Invalidierung.

Lochstanzen fällt in Kategorie # 2 :)

Allgemeines

Der beste Ansatz ist, an den unteren Punkten des Stapels zu beginnen und bis zum Frontend von Magento zu optimieren.


Datenbank und Dateisystem

Sollte immer der erste Bereich sein, auf den man sich konzentriert. Weil. I / O.

MyTop ist ein handliches Linux-basiertes Perl-Skript, das den Linux-Befehl 'top' nachahmt und Ihnen einen Einblick in den Status Ihrer MySQL-Instanz (en) gibt.

Htop ist ein robusteres Top . Die Strace- Funktion kann dabei helfen , die Details eines Prozesses zu bestimmen, um potenzielle Engpässe zu finden.

Iotop ist ein weiteres zu berücksichtigendes Tool für die Überwachung von E / A.

Andere nützliche Hilfsskripte wie mysqltuner.pl und mysql tunning primer bieten einen Einblick in Ihre MySQL-Laufzeitvariablen und geben Ratschläge zur Hilfe. Denken Sie daran, dass dies nur als Leitfaden dienen soll, da der beste Ansatz immer eine Bewertung der Anforderungen und der Abstimmung auf der Grundlage der gesammelten bekannten Daten ist. Blinde Handlungen können manchmal mehr Schaden anrichten als nützen. Und wenn Sie diese vorzeitig ausführen, ohne mindestens 24 Stunden MySQL-Laufzeitvariablen zu haben, kann dies einen schlechten Ratschlag darstellen.

Denken Sie daran , dass Percona , MariaDB und Standard-MySQL mit all diesen Funktionen funktionieren sollten. Bevorzugen Sie Percona als MySQL-Fork, da Magento InnoDB und XtraDB so stark belastet, dass es viele Tools und Verbesserungen für die Datenbank-Engine bietet.


Apache oder Nginx

Ich benutze immer noch Apache, da es vielen anderen gute Dienste geleistet hat, auch mir. Ich habe auch Nginx benutzt und konfiguriert. Während es einige Vorteile bietet, gibt es eine Lernkurve. Während die beiden populären Optionen sind, bietet es einige Vorteile gegenüber Apache, eine wäre ein kleinerer Speicherbedarf. Ein schlanker Apache, auf dem PHP-FPM ausgeführt wird, hat jedoch einen ähnlichen Speicherbedarf.

Ein typisches Beispiel:

Da es in diesem Artikel um die Leistung ging, sollte ich darauf hinweisen, dass eine der einfachsten Möglichkeiten, Apache dabei zu unterstützen, seinen eigenen Weg zu finden, darin besteht, keine .htaccess-Dateien zu verwenden. Wenn Sie das, was Sie dort gespeichert haben, in Ihre Directory-Zeilengruppen aufnehmen, AllowOverride auf "None" setzen und Apache nicht aufgefordert wird, den gesamten Dokumentpfad zu durchlaufen, um herauszufinden, ob .htaccess beachtet werden muss oder nicht. Dies ist ein grundlegender, einfacher Abstimmungshinweis, den viele Leute vermissen.

So erleichtern Sie das Auschecken:

Die Verwendung eines CDN, um beide Probleme zu lösen, ist offensichtlich hilfreich, hat jedoch einen zusätzlichen Vorteil bei der Frontend-Optimierung, da die meisten Endbenutzer-Browser mit der gleichen Anzahl von Verbindungsbeschränkungen eine Verbindung zu beiden Servern herstellen können. Dies befreit Apache auch davon, nicht durch Prüfungen springen zu müssen, um nur ein einfaches statisches Image bereitzustellen. Lighthttpd ist eine Option, wenn Sie einen statischen Webserver nur für Inhalte neben einem CDN ausführen möchten.

PHP

PHP-FPM und APC. Verwenden Sie sie, entfernen Sie nicht benötigte oder nicht benötigte PHP-Module, die für Magento nicht benötigt werden.


Magento-Codebasis

Mit AOE_TemplateHints können Sie feststellen, ob Ihre Blöcke ordnungsgemäß zwischengespeichert werden:

AOE_Profiler eignet sich gut für die Profilerstellung. Stellen Sie sicher, dass die Profilerstellung für die DB-Ebene aktiviert ist (in einer lokalen / dev-Umgebung natürlich). Dies in Verbindung mit dem oben erwähnten Tool mytop erleichtert das Auffinden von SQL- Fehlern .

Module von Drittanbietern und benutzerdefinierter Code

Einige sehr gute Best Practices für die Optimierung von Magento selbst sind eine gute Lektüre und sollten beachtet werden, wenn Module von Drittanbietern überprüft werden, bevor sie verwendet werden. (Es gibt viele schlechte Verhaltensweisen, IMO).

Mit dem Tool Magniffer von Magento ECG können Sie auf der Grundlage des oben bereitgestellten PDF-Dokuments leicht Code identifizieren, der sich schlecht verhält. Es ist Symfony / PHP-Parser-basiert, aber über Composer installierbar.


Lack

man schaltet den lack nicht einfach ein

Als Verfechter von Varnish, der als Autor ein FreeBSD-Kernel-Entwickler war, bietet es einige verrückte Sub-Sekunden-Ladezeiten. Wenn Sie jedoch auch nur einige der geringfügigsten Unterschiede in Ihren Vorlagen haben, die nicht im Auslieferungszustand sind, müssen Sie Lack / Magento so konfigurieren, dass der benötigte Inhalt vollständig gelocht wird. Das meiste, was ich gesehen habe, wird einfach AJAX'ify die benötigten Gegenstände ungecacht von Lack.

Es gibt eine Reihe von Magento-Modulen, die das Lochen und Zwischenspeichern erleichtern:

Letztlich soll dies am letzten Ende der Optimierung Reise sein, und KöNNTE einige Anpassungen erfordern Dinge richtig zu machen.


Magento CE FPC

Bisher ist die beste CE-FPC, die ich gefunden habe: Lesti :: FPC

Es ist eine sehr gut zusammengestellte (alle Beobachter basierende) Open Source und kostenlose FPC für die Community.


Am Ende des Tages verwenden Sie Ihre eigenen Tests und Beurteilungen.

Einige weitere Lektüre:

B00MER
quelle
2

Ich weiß, dass dieser Thread etwas spät ist, aber wenn Sie immer noch nach einer Lösung suchen, sollten Sie Evolved Caching in Betracht ziehen . Es ist der gleiche Preis wie Warp, aber es:

  • Ist sehr schnell und einfach zu installieren und zu konfigurieren - das gesamte Lochen und Konfigurieren erfolgt über den Administrator
  • Integriert sich direkt in Varnish und ermöglicht es Ihnen, Ihren Varnish-Cache in Magento zu leeren und aufzuwärmen
  • Funktioniert mit dem in 1.8 CE eingeführten Frontend form_key sowohl in Varnish als auch im eigenen Cache.
  • Ist sehr aktiv mit reaktionsschneller Unterstützung entwickelt. Regelmäßige neue Versionen mit dem Ziel, Fehlerbehebungen innerhalb weniger Tage nach der Berichterstellung zu veröffentlichen
  • Verfügt über eine umfangreiche Dokumentation, die mit jedem Release aktualisiert wird

Einstellung mit Firnis nach oben ist gerade nach vorne, Sie müssen nur eine Admin - Einstellung aktivieren und verwenden Sie die .vcl gefunden hier . Sie sind auch nicht darauf beschränkt, nur den Cache von Varnish zu bedienen, wenn keine Cookies wie gewohnt vorhanden sind - Sie erhalten eine sehr hohe Cache-Trefferquote.

Jonathan Hussey
quelle
Oh wow, interessant. Ich werde das auf jeden Fall untersuchen. Ich sollte hier ein Update posten. Grundsätzlich habe ich mich für Varnish entschieden und nicht für ein ganzseitiges Cache-Modul, aber ich habe mich ein wenig damit beschäftigt, was ich mit den dynamischen Teilen anfangen soll. Zum größten Teil ESI gegen AJAX. Ich habe Lack mit Terpentin ausprobiert, aber als ich Probleme hatte, Sachen in den Wagen zu legen, habe ich daran gezogen. Es stellte sich heraus, dass die Probleme mit meinem gespeicherten Session-Save-Handler zu tun hatten, was ich später herausfand. Trotzdem möchte ich Varnish wieder auf Vordermann bringen, muss aber einige Zeit darauf verwenden, sicherzustellen, dass alle meine dynamischen Portionen einwandfrei funktionieren.
ThatSourDiesel
1
Sicher, OK. Ich glaube nicht, dass Terpentin noch mit 1.8 CE funktioniert, da form_key im Frontend enthalten ist. Dies könnte der Grund dafür sein, dass Sie Probleme mit add to cart hatten. Persönlich würde ich Ajax gegenüber ESI empfehlen, hauptsächlich, weil ESI erfordert, dass Sie eine Anfrage an Magento senden, bevor die Seite geliefert wird, und dies wird immer langsam sein. Vielleicht interessiert es Sie, diesen Beitrag anzuschauen. fabrizio-branca.de/magento-varnish-ajax-vs-esi.html .
Jonathan Hussey
Ich liebe Fabrizios Blog! Auf jeden Fall gesehen, dass AJAX-Modul von ihm - das ist, worauf ich mich bezog, als ich AJAX in meinem letzten Kommentar erwähnte. Das Add-to-Cart-Problem, das ich hatte, lag an etwas Seltsamem mit Memcached, das ich tatsächlich beheben konnte. Das heißt, obwohl sie sagen, dass Terpentin nicht mit 1.8 funktioniert, es sei denn, Sie deaktivieren den form_key, schien es gut für mich zu funktionieren. Da ich ESI zu diesem Zeitpunkt noch nicht vollständig verstanden hatte, wurde es deaktiviert, bis ich mehr Zeit für die Implementierung und das Testen aufwenden kann. Ich habe vor kurzem ein bisschen Arbeit verpasst - Schlüsselbein gebrochen, musste operiert werden.
ThatSourDiesel
Übrigens, Evolved Caching ist dein eigenes Modul? Nur aus Neugier - wären Sie bereit, mich auf meinem Staging-Server testen zu lassen? Wir können in PM-Domänennamen diskutieren und was nicht, damit Sie überprüfen können, ob es sich tatsächlich um einen
Testserver
Ich hoffe, Sie erholen sich nach Ihrer Operation! Ja, das Modul wurde von meiner Firma entwickelt und wir freuen uns, dass Sie es auf einer Staging / Dev-Domain testen können. Schreiben Sie uns einfach eine E-Mail mit der E-Mail-Adresse des Kundendienstes in der linken Spalte unseres Shops und ich hole sie ab - store.husseycoding.co.uk . Als Randnotiz, froh, dass feste Sie die Memcached Ausgabe, erwähnenswert, vielleicht , dass In der Warenkorb kann erscheinen zur Arbeit unter 1,8 für den Benutzer, den die Seite Cache verursacht als ihre Form Schlüssel auch zwischengespeichert wird, aber Ihre Cookies löschen , einen neuen zu erhalten Session + Formular-Schlüssel und Sie werden wahrscheinlich feststellen, dass es fehlschlägt.
Jonathan Hussey
1

Wir haben eine FPC geschrieben, die mit dem neuen Formularschlüssel von Magento 1.8 kompatibel ist. Brims ganzer Seiten-Cache: http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER legt großen Wert darauf, möglichst wenig zu stapeln und sich nach oben zu arbeiten. Ein FPC oder Lack sollte ungefähr das Letzte sein, was Sie tun. Wir führen Leistungsprüfungen durch und stellen häufig Probleme mit MySQL- und APC-Konfigurationen fest, die einfach nicht stimmen. Wie Innodb Puffergrößen auf den Standard gesetzt und die Datenbank ist weit darüber hinaus gewachsen.

Wir empfehlen, kein FPC mit Lack zu verwenden, es sei denn, dies wurde speziell für die Zusammenarbeit entwickelt. Im Allgemeinen empfehlen wir Varnish nicht, es sei denn, Sie haben eine Handvoll leistungsfähiger Server, die alle zusammen mit Ihrer Codebasis optimiert wurden und immer noch Probleme haben, mit dem Datenverkehr Schritt zu halten. Das Aktualisieren dynamischer Inhalte kann mit Varnish schwierig sein, insbesondere wenn Sie versuchen, Ihre Anforderungen auf das Magento-Backend zu beschränken und damit die Last zu reduzieren. Wenn Sie einen oder zwei Webköpfe haben, sind die Gewinne möglicherweise die Zeit und die Komplikation nicht wert.

In den meisten Situationen erhalten Sie mit einem guten FPC die Leistung, die Sie benötigen, natürlich nachdem Sie Server und Codebasis optimiert haben. Mit unserer FPC können Sie Erzeugungszeiten unter 15 ms für den Level 1-Cache und unter 100 ms für den Standard-Cache erhalten. Unser Level-1-Cache wird für Fälle verwendet, in denen der Benutzer nicht angemeldet ist und nichts in seinem Einkaufswagen hat, da kein Lochen ausgeführt wird. Wenn eine dieser Bedingungen falsch ist, wird der Standard-Cache mit voller Lochunterstützung verwendet.

Unser FPC verfügt über eine integrierte, einfache Lochung und funktioniert sofort mit allen Standard-Magento-Blöcken sowie allen benutzerdefinierten Blöcken, die Sie möglicherweise haben. Es ist alles über das Admin-Panel konfigurierbar.

Ich würde empfehlen, bei Redis zu bleiben, es sei denn, Sie haben Skalierungsprobleme. Es unterstützt Tags und ist viel schneller als das Speichern von Dateien oder Datenbanken als langsames Backend. Wenn Sie konsistente Tags und Bereinigung wünschen, müssen Sie memcached with database verwenden, wenn Sie mehrere Webköpfe haben. Dank der integrierten Tag-Unterstützung von Redis müssen Sie sich keine Sorgen mehr machen. Sie können Redis auch für Ihre Sitzungen verwenden.

Ich kann für alle FPCs sprechen, aber bei uns können Sie über den Administrator konfigurieren, wo sie gespeichert werden sollen. Sie können das standardmäßige Magento-Cache-Backend verwenden oder benutzerdefinierte Einstellungen für die Verwendung von Datei, Datenbank, APC, Redis, Memcache und einem optimierten Datei-Backend festlegen.

BrimSeth
quelle
Kann für eine Zustellung unter 20 ms an den Browser bürgen. Nur Magento FPC habe ich gesehen, wie es in einem echten Live-Shop gemacht wurde.
Melvyn
0

Es gibt keine richtige Antwort. Ein Geschäft sollte über dynamische Seitenladevorgänge von weniger als 3 Sekunden und im Idealfall über dynamische Seitenladevorgänge von weniger als 1 bis 2 Sekunden verfügen. Eine Sekunde ist nicht erforderlich und in erster Linie eine marketingbasierte Statistik. Apache ist leicht zu erlernen und schwer zu implementieren, Nginx ist schwer zu erlernen und leicht zu implementieren. Viele Websites wechseln zu Nginx. Eine qualitativ hochwertige Architektur auf der Basis von Nginx und Magento ist jedoch nicht einfach.

Magento-Cluster mit mehreren Servern sind bereits komplex zu implementieren und noch schwieriger zu warten, wenn nicht die richtige Architektur verwendet wird. Normalerweise arbeiten wir mit größeren Clustern, wodurch alles reibungsloser funktioniert, auch das Ranking. Wir tun dies mit der Standardinstallationskonfiguration mit geringfügigen Änderungen für mittel- bis langfristige Stabilität, die auf die dynamischen Seitenladevorgänge von 1-2s abzielen. Dies vereinfacht die Wartung erheblich.

Lack kann eine FPC sein, unter anderem eine CDN. In Ihrem Fall ist es jedoch am besten, sich eine FPC vorzustellen. Ein FPC ermöglicht mehr Besucher auf dem Server und eine schnellere statische Bereitstellung, wobei Varnish ein solches Tool ist. Es gibt jedoch verschiedene Probleme, einschließlich dynamischer Inhalte, Bestandskontrolle und Preisgestaltung. Die Antwort hängt davon ab, wie Ihr Unternehmen strukturiert ist, wie Ihre Daten geladen werden, wie häufig Ihre Hosting-Art und mehr, und einfach davon, ob Ihr Unternehmen statische Inhalte für Besucher bereitstellt. Mit der FPC-Konfiguration können Sie einen Großteil davon technisch abmildern, was jedoch die Geschäftsumgebung kompliziert. Aus Sicht des Geschäftsinhabers führt dies möglicherweise nicht zu einer ausgewogenen Kapitalrendite.

Die FPC ist der letzte Teil, wenn Sie eine dynamische Belastung von weniger als 3 Sekunden oder besser haben. Ihre Architektur kann eine Vielzahl von Besucheranfragen bewältigen, da dies das Ranking beeinflusst, Marketing- und Urlaubsspitzen absorbiert und das Budget zur Erhöhung der Komplexität der Serverarchitektur ausreicht. Das Hosting sollte 0,5 betragen -1% des Umsatzes für kleinere Unternehmen, wobei die meisten davon erheblich darunter leiden und viele indirekte geschäftliche Probleme verursachen.

Der Grund, warum Sie keine endgültige Antwort gefunden haben, liegt in der Tatsache begründet, dass die Beantwortung dieser Fragen Monate dauert, da sie qualitativ sind (geschäftsbezogen) und Informationen erfordern, die ein Unternehmen nicht öffentlich veröffentlichen möchte. Die Seitenladegeschwindigkeiten sind quantitativ (technisch) ) die öffentlich veröffentlicht werden kann, ist es, wie Sie die beiden kombinieren, die die Lösung macht.

VanquishTechnology
quelle
-2

Sie können diesen Magento-Seiten-Cache verwenden, der Ihren Anforderungen entspricht und lackähnlich ist. Es wird von vielen der größten Magento-Stores genutzt. Einige Eigenschaften:

  1. Wie bei Varnish wird für 90% der Anforderungen keine Datenbankverbindung verwendet. Infolgedessen ist es extrem schnell
  2. Es kann Seiten automatisch leeren, wenn sich beispielsweise das Produktinventar ändert, und das ist sehr gut
  3. Da es sich um einen mehrschichtigen Cache handelt, wird auch das Lochen beim Anmelden von Benutzern unterstützt (diese Anforderungen erfordern die Verwendung der Datenbank).

Als mehrstufiger Cache ist er selbst für Läden mit hohem Datenaufkommen skalierbar und wurde auf vielen Websites mit extrem hohem Datenaufkommen verwendet, auf denen der Datenverkehr am höchsten ist, z.

Extendware
quelle
Dies beantwortet nicht die Frage des Autors, ob Lack oder FPC verwendet werden soll.
Steve Robbins
@extendware müssen Sie angeben, wenn Sie der Autor eines Produkts sind. Wir freuen uns über wertvolle Beiträge, begrüßen jedoch keinen direkten Spam.
Philwinkle