2009-01-08 6 views
5

Ich hatte das Glück, keine cgi-bin .cgi basierte Webentwicklung zu machen. Aber im Allgemeinen scheinen diejenigen, die diese Tage nicht "vermisst" haben.Was waren die Hauptnachteile der CGI-BIN basierten Webentwicklung?

Ein Projekt, dem ich kürzlich beigetreten bin, hat ein Leistungsproblem beim Umgang mit den Seiten, die mit einem Altsystem kommunizieren müssen, das über eine CGI-BIN-basierte API verfügt. Dieses System ist COGNOS 7.

Die Rückmeldung, die ich bis heute erhalten habe, ist, dass COGNOS langsam ist, aber andere haben großen Erfolg mit COGNOS berichtet, ich denke, es hat mehr mit dem Zugriff über CGI-BIN und nicht die Leistung von COGNOS an und für sich.

Alles, was gesagt, was die wichtigsten Fragen, die CGI-BIN-basierte Web-Entwicklung nicht-performanten, schwierig, etc ...

Antwort

4

Das grundlegende Architekturproblem bei CGI-BIN-basierten Systemen besteht darin, dass jede HTTP-Anforderung erfordert, dass der Server einen neuen Prozess startet. Dies beeinträchtigt die Leistung in einer Reihe von Möglichkeiten:

  • Es ist teuer, den Prozess, wie die OS-Seiten im Programm zu starten, um den Prozess einrichtet, usw.
  • Ressourcen können nicht über Anfragen geteilt werden, so dass alle DB-Verbindungen, haben usw. mit jeder Anforderung
  • Benutzersitzungsstatus wird nicht im Speicher aufbewahrt eingerichtet werden, so hat es mit jeder Anforderung
+1

Diese Einschränkungen gelten im Allgemeinen für CGI, sie sind nicht spezifisch für CGI-BIN. Du hast natürlich immer noch recht, ich dachte nur, ich würde diesen Kommentar machen. –

+0

Es * kann * teuer sein, einen Prozess zu starten. Im Allgemeinen machen Unix-ähnliche Betriebssysteme Prozesse billig und fördern Forking-Prozesse wann immer nötig; Windows-Betriebssysteme machen Prozesse teuer und unterstützen stattdessen das Erstellen von Threads. Jeder Ansatz hat seine Vorzüge; Das CGI-Modell wurde ursprünglich in Unix-Umgebungen entwickelt, so dass der Aufwand für die Erstellung von Prozessen nicht als problematisch angesehen wurde. (Auf der anderen Seite, wenn Sie Ihren Prozess erstellen, müssen Sie etwas wie einen Perl/Python/etc. Sprachinterpreter starten, dann steigt der Overhead um eine Grössenordnung von mindestens ...) –

0

Der Hauptnachteil, IMHO gemacht, den gleichen Nachteil war, dass all untergeordnete Codierung hat - anstatt in der Problemdomäne zu programmieren, musste man in der Implementierungsdomäne programmieren. Das Endergebnis war im Wesentlichen identisch - eine HTTP-Antwort wurde basierend auf einer HTTP-Anfrage an einen Client gesendet. Jedoch, bis zu bekommen, war dieser Punkt aus Programmiersicht viel kniffliger.

+0

Nichts darüber, wie der Webserver mit der Anwendung kommuniziert hat irgendeine Verbindung zu, wie schwer es ist, "an den Punkt zu kommen" – Quentin

+0

@David Dorward: Du hast absolut Recht. Bei der Entwicklung zur CGI-Oberfläche haben Sie es jedoch mit allen Details der unteren Ebenen in jeder Anwendung zu tun. Frameworks, ob ASP.NET, Rails, Django oder irgendetwas anderes, erlauben es dem Programmierer, sich auf die Problemdomäne zu konzentrieren und sich nicht um die Details des Kommunikationsprotokolls zu sorgen, was dem Programmierer erlaubt, "an den Punkt zu kommen" Anwendung, anstelle der CGI-Spezifikation. –

1

Für mich ist der größte Schmerz mit CGI beharrte werden soll dass meine CGI-Programme bei jedem Start alles "lernen" müssen. Wenn sie ständig liefen, wäre das natürlich nicht der Fall ...

0

Apache hat mehrere Lösungen für verschiedene Sprachen (zB mod_perl), so dass ein Skript nur einmal aufgerufen und dann schnell im Speicher gehalten wird Abruf. Es gibt immer noch eine Menge von GCI-Protokoll-getriebenen Websites, von denen viele mit einigermaßen niedriger Latenz laufen, wenn sie gut codiert und eingerichtet sind.