Mason CMS
CMS-Serie: Mason
Das Perl-basierte Open-Source-CMS Mason steht für extreme Skalierbarkeit und kommt daher selbst auf Websites wie Amazon.com zum Einsatz.
- CMS-Serie: Mason
- Teil 2: CMS-Serie: Mason
- Teil 3: CMS-Serie: Mason
- Teil 4: CMS-Serie: Mason
Wer ein CMS-Entwicklungssystem sucht, das von der kleinsten Ausbaustufe einer Mini-Webseite bis hin zu milliardenschweren Web-Portalen klaglos alles mitmacht, sollte einen Blick auf Mason werfen.
Mason ist eine leistungsfähige Perl-basierte Website-Entwicklungs- und Delivery-Engine mit einer integrierten Template-Engine. Mittels Mason können Sie Perl-Code in HTML einbinden und gemeinsam nutzbare, wiederverwendbare Komponenten erstellen.
Eine Mason-Komponente besteht aus HTML-Code-Snippets, Perl-Anweisungen und Mason- spezifischen Befehlen. Konkrete URL- Anfragen eines Clients werden durch Mason als Aufrufe der jeweiligen Komponenten umgesetzt. Dieser objektorientierte Ansatz erlaubt es, die verwalteten Inhalte von der grafischen Darstellung der Seiten zu trennen.
Perl-Vorurteile
Das Klischee, CGI und Perl seien langsam, trifft nur deswegen zu, weil statt des moderneren FastCGI allzu oft das veraltete CGI zum Einsatz kommt. Wer E-Commerce-Lösungen realisieren möchte, der muss mit der Zeit gehen. Das bedeutet den Einsatz der aktuellen Version des Apache-Webservers (also 2.2) mit aktuellen Versionen der benötigten Module (mod_perl 2.04 und mod_fastcgi 2.4.6) und CPAN-Module.
Eine hochperformante Perl-Version (derzeit 5.8.8) ist sehr empfehlenswert genauso wie auch eine zeitgemäße Implementierung von CGI, also FastCGI. Wer die beste Leistung erzielen will, sollte sich zumindest in den Grundzügen mit der GNU GCC-Entwicklungsumgebung auskennen und in der Lage sein, sich aus den Quellen eine maßgeschneidert optimierte FastCGI-Version zu kompilieren.
In der Praxis neigen viele Anwender dazu, aus Zeitgründen dem Kompilieren von Quelltexten aus dem Weg zu gehen, nehmen lieber eine veraltete CGI-Installation out-of-the-box und kommen dann natürlich zu dem Schluss, dass CGI und damit auch Perl- und CGI-basierte Lösungen langsam seien.
In der Praxis zeigt sich aber gerade am Beispiel von Mason, wie leistungsfähig bereits eine Kombination aus FastCGI und Perl sein kann. Bei FastCGI handelt es sich im Grunde genommen um nichts anderes als um CGI mit ein paar wenigen Zusatzerweiterungen. Es wirkt sich wie ein Turbo-Booster auf die Performance Perl-basierter Lösungen aus.
Sowohl bei CGI als auch bei FastCGI laufen die Prozesse isoliert von denen des Webservers. Nur wenn man den veralteten CGI-Ansatz mit aufgeblasenen Webserver-APIs, die für alle nötigen und auch unnötigen Eventualitäten Sorge tragen, kombiniert, geht es sowohl zulasten der Performance als auch der Sicherheit, denn APIs verschmelzen verschmelzen den Applikationscode mit dem Code des Webserver-Core.
Einer der Gründe, warum immer noch CGI statt FastCGI zum Einsatz kommt, ist Unwissen. Oft werden die benötigten Bibliotheken, die FastCGI in populären Sprachen wie C/C++, Sun Java, Ruby, Perl oder Tcl zugänglich machen, ignoriert. Auch die notwendigen Upgrades für beliebte Webserver wie Apache, ISS, Lighttpd, My Server, Pi-3-Web, Premium thttpd oder Webstar scheinen nur wenige zur Kenntnis zu nehmen.
FastCGI ist wie CGI nicht an die interne Struktur des Webservers gekoppelt, sodass im Falle von Änderungen an der Webserver-Technologie alles unverändert weiterläuft. Wer hingegen auf API-basierte Applikationen gesetzt hat, wird bei einer Änderung am Webserver auch mit einer neuen API leben und daher seine API-basierte Applikation umschreiben müssen.
