Lazarus-Treffen in Oldenburg Samstag, 10.12.2017 um 19:00 Uh

Alle Informationen zu Treffen der regionalen Lazarus-Gruppen
Devstructor
Beiträge: 32
Registriert: Mi 7. Sep 2016, 18:27
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: xxBit
Kontaktdaten:

Re: Lazarus-Treffen in Oldenburg Samstag, 10.12.2017 um 19:0

Beitrag von Devstructor »

pluto hat geschrieben:Da ist CGI natürlich einfacher, ist das nicht inzwischen Veraltet?


Naja,

CGI hat wie vieles im Leben Vor- und Nachteile. Vorteil ist auf jeden Fall, dass man es einfach in fast jede Webserver-Software einbauen kann, denn CGI ist ein Standard. Heute wird aber für dynamische Webseiten lieber z.B. PHP verwendet. Der Grund dafür ist ganz einfach. CGI ist eine sehr statische Lösung. Der Webserver führt dann eine Anwendung aus. Diese Anwendung kann nicht einfach geändert werden. Wenn man in PHP einen Aspekt ändern möchte, kann man einfach irgendein Editor nehmen und die php-Datei bearbeiten. Das hat natürlich auch Nachteile, denn durch PHP sind in der Vergangenheit sicher viele Webserver hackt worden. Ein weiterer Vorteil ist die Geschwindigkeit von PHP. Wenn man nur ein Hello World ausgeben möchte, ist das in 3 Zeilen gelöst, während man in Lazarus noch im Dialog für ein neues Projekt steckt.

Doch in dem Captcha Aspekt brauchte ich keine dynamische Lösung, weitergehend ist die Thematik auch nicht in 3 Zeilen gelöst. Ich brauchte eine Server-Komponente, die sich mit einer DB verbindet, einen Code lädt und daraus ein Bild generiert. Das sind dann schon nicht ganz triviale Aufgaben, so eine Aufgabe wollte ich nicht in PHP lösen, weil ich das unter Lazarus schneller löse. Denn wichtig war mir auch, dass ich nicht irgendwelche third Party PHP-Skripte verwende.

Bei dieser Aufgabe hatte CGI deutliche Vorteile. Die Entwicklung war für mich einfach und es ist zusammengefasst eine schnelle Lösung. CGI kann in diesem Bereich schneller als PHP sein, vor allem wenn man FastCGI verwendet. Der grundliegende Unterschied dabei ist, dass bei FastCGI eine Hand voll Instanzen der Anwendung gestartet werden und dass diese dann in Schleifen die Anfragen abarbeiten. Dadurch muss nicht jedes mal eine neue Anwendung gestartet werden. Außerdem müsste dabei in meinem Fall nicht jedes mal die Firebird-Lib geladen werden und die DB-Connection aufgebaut werden. Dadurch wäre die Lösung deutlich schneller als PHP.

Ich habe aber keine FastCGI-Anwendung gemacht, sondern nur eine Standard CGI-Anwendung, denn bei meinem Nutzerzahlen macht das kaum einen Unterschied. In einem Test habe ich die Performance verglichen. Dabei wurde die Zeit in ms gemessen, von der HTTP-Anfrage, über das Laden der Firebird Lib, aufbauen der DB-Verbindung, DB-Abfrage, Erstellen der Graphik, Übermitteln des Ergebnis via HTTP zum Client.

Bei 100 parallel Nutzern:
CGI (nicht FastCGI!): 139ms avg.
PHP: 119 ms avg.

Mir reicht das, wenn ich jemals mehr bräuchte könnte man über FastCGI nachdenken. Dann wäre man sicher im Bereich von 50..75 ms.

LG
Miguel :)
www.devstructor.com Devstructor.com - Lazarus Tutorials and more

Antworten