zurück zur Startseite
  


Zurück XHTMLforum > Webentwicklung (außer XHTML und CSS) > Serveradministration und serverseitige Scripte
Seite neu laden Variable an nächstes Request weitergeben

Antwort
 
LinkBack Themen-Optionen Ansicht
  #1 (permalink)  
Alt 15.03.2012, 12:20
Erfahrener Benutzer
XHTMLforum-Mitglied
Thread-Ersteller
 
Registriert seit: 09.10.2010
Beiträge: 151
MitjaStachowiak befindet sich auf einem aufstrebenden Ast
Standard Variable an nächstes Request weitergeben

Hallo,
ich poste mal die komplette Storry, müsst ihr aber nicht alles lesen :

ich habe für meine Schule dieses Messdatenupload programmiert: *http://www.hems-renewables.de/pv-anlage-der-hems/messwerte.html*

Jetzt versuche ich, die Werte dauerhaft zu speichern und die Sicherheitsstandards zu erhöhen. Es gibt immer einen Clienten, der eine dauerhafte Verbindung mit dem Server haben soll. Weil ich auf dem Server nur Perl und PHP-Scripte laufen lassen kann (Im Moment Perl), bleibt mir nichts anderes übrig, als ein HTTP-Request zu verwenden. Wenn sich der Client nun einloggt, wird ein Zufallspasswort erstellt, das als Basis für verschiedene Hashcodes und fortlaufende Zufallsalgorithmen dient. Das Upload soll so sicher sein, dass man, auch wenn man die Kommunikation mit dem Server abhört, sich nicht einhacken kann. Ein Schutz vor Datenmanipulation soll aber nicht integriert sein. Also sende ich mit jedem Request eine Pseudo-Zufallszahl mit, die auf Server und Client die gleiche Sequenz hat. So kann man sicherstellen, dass niemand unbefugtes etwas hochlädt.
Aber der Server muss das Passwort und die aktuellen Sequenzen der Zufallszahlen mit jedem Request weitergeben. Mir bleibt nichts anderes übrig, als alle Variablen in Dateien abzuspeichern. Dass das keine hohe Performance hat, ist klar.
Ich kenne nur einen Weg, das zu umgehen: FastCGI. Leider haben wir es nicht geschafft das zu installieren, weder auf dem Server, noch lokal in einem Apache Man findet im Internet fast keine brauchbaren Tutorials, ich habe ewig gesucht...


Dann der Hinweis, man könne in PHP Variablen global definieren und die würden dann zum nächsten Request weitergegeben werden. Aber ich finde nichts dazu.

Also: Wie kann man Variablen so anlegen, dass man in jedem Request darauf zugreifen kann? Wie macht das zum Beispiel dieses Forum? (Die Lösungen mit "in Datei speichern", oder "dem nächsten Request anhängen" kommen nicht in Frage).
Mit Zitat antworten
Sponsored Links
  #2 (permalink)  
Alt 15.03.2012, 12:58
Erfahrener Benutzer
XHTMLforum-Mitglied
 
Registriert seit: 13.07.2006
Beiträge: 747
mermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblick
Standard

Zitat:
Mir bleibt nichts anderes übrig, als alle Variablen in Dateien abzuspeichern. Dass das keine hohe Performance hat, ist klar.
Hast du messbare Performance-Probleme bekommen durch das Ablegen der Daten in Dateien oder vermutest du das nur?
Mit Zitat antworten
Sponsored Links
  #3 (permalink)  
Alt 15.03.2012, 13:58
Erfahrener Benutzer
XHTMLforum-Mitglied
 
Registriert seit: 13.07.2006
Beiträge: 415
Maxefix ist ein sehr geschätzer MenschMaxefix ist ein sehr geschätzer MenschMaxefix ist ein sehr geschätzer Mensch
Standard

Gehören die Datem zum Client und sollen nicht dauerhaft gespeichert werden: Sessions. Ansonsten sind Textdateien schonmal eine gute Wahl. Es wäre natürlich auch eine Datenbank denkbar, aber das musst du selbst entscheiden ob dir das einen Vorteil bringen würde.

Textdateien sind übrigens nicht per se langsam.

Gruß,
Max
Mit Zitat antworten
  #4 (permalink)  
Alt 15.03.2012, 15:25
Erfahrener Benutzer
XHTMLforum-Mitglied
Thread-Ersteller
 
Registriert seit: 09.10.2010
Beiträge: 151
MitjaStachowiak befindet sich auf einem aufstrebenden Ast
Standard

Messbare Performanceprobleme habe ich keine, aber dieses ständige Speichern in Dateien ist schon eine Belastung für die Hardware: Verwendet der Server eine HDD, so wird er durch die Zugriffszeiten ständig kurzfristig lahmgelegt (Was sich nicht im betreffenden Script selbst äußern dürfte, sondern eher in der Reaktionszeit allgemein). Verwendet der Server eine SSD, so verkürzen die Schreibzugriffe nur die Lebensdauer.

Wie man's auch dreht und wendet - Variablen in Dateien abzuspeichern halte ich nicht für die beste Lösung. Für die Messwerte selbst ist das in Ordnung, weil die ja immer verfügbar sein sollen, aber wenn mal der Key verloren geht, bedeutet das nur, dass der Client die Verbindung neu aufbauen muss. Das passiert sowieso schon regelmäßig bei der täglichen Serverwartung, weil dann die Antwortzeit so groß ist, dass die Verbindung beendet wird.

Das mit den Sessions ist eine gute Idee, aber wenn ich mir den Quellcode davon ansehe, würde ich behaupten, dass das auch in Dateien gespeichert wird (Die Webdesign-Referenz (eBook): Session-Management mit Perl)
Mit Zitat antworten
  #5 (permalink)  
Alt 15.03.2012, 15:33
Benutzerbild von protonenbeschleuniger
Verbesserer
XHTMLforum-Kenner
 
Registriert seit: 06.09.2007
Beiträge: 4.953
protonenbeschleuniger ist ein wunderbarer Anblickprotonenbeschleuniger ist ein wunderbarer Anblickprotonenbeschleuniger ist ein wunderbarer Anblickprotonenbeschleuniger ist ein wunderbarer Anblickprotonenbeschleuniger ist ein wunderbarer Anblickprotonenbeschleuniger ist ein wunderbarer Anblickprotonenbeschleuniger ist ein wunderbarer Anblick
Standard

Du kannst Perl Sessions auch mit einer Datenbank koppeln CGI::Session - search.cpan.org
Wobei ich aber eine mySQL deutlich langsamer ist, als das abspeichern als Datei. Das von dir angesprochene bewegt sich im Bereich weniger Millisekunden oder sogar darunter, eine DB wird über das Netzwerk angesprochen was immer langsamer ist. DB haben ihren Vorteil bei grossen Datenmengen und Abfragen, was aber in dem Fall eher nicht so deutlich in's Gewicht fällt.
Mit Zitat antworten
  #6 (permalink)  
Alt 15.03.2012, 15:34
Benutzerbild von Praktikant
Semantikbremse.
XHTMLforum-Kenner
 
Registriert seit: 22.04.2008
Beiträge: 4.989
Praktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz seinPraktikant kann auf vieles stolz sein
Standard

Stimmt. Sessions werden in Dateien gespeichert. Sowohl auf dem Server, wie auch auf dem Client.
Eine Datenbank ist auch nicht viel mehr als eine Speicherung von Daten in Dateien. Da wirst du nicht drum herum kommen. Wenn etwas von einem Request in einen anderen übernommen werden soll, dann muss es irgendwo hingeschrieben werden. Es soll ja nicht verloren gehen. Da bleibt dann nur noch die Festplatte (egal ob HDD oder SSD).
__________________
Rettet die Erde.... sie ist der einzige Planet mit Schokolade!
Mit Zitat antworten
  #7 (permalink)  
Alt 15.03.2012, 15:49
Erfahrener Benutzer
XHTMLforum-Mitglied
 
Registriert seit: 13.07.2006
Beiträge: 747
mermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblick
Standard

In PHP gibt es beispielsweise PHP: APC - Manual. Damit können Daten requestübergreifend im RAM abgelegt werden.

Ich halte die Formulierung dieses „Problems“ aber für eine totale Fehleinschätzung.

Wenn du Effekte dieser Größenordnung beachten müsstest, würdest du nicht das vorgestellte Setup nutzen.

Anders ausgedrückt: Du feilst an deinem Fahrrad-Schutzblech nicht den Rahmen flacher, um in einem Formel-1-Rennen konkurrenzfähig zu sein.

Ich kann nur davor warnen, sich aus Prinzip auf die „Optimierung“ nebensächlicher Aspekte einzuschießen. Die Zeit fehlt dann anderswo, wodurch ein wirklich wichtiger Teil nicht so gut designt wird, wie er designt werden könnte. Dadurch verlierst du dann im Verhältnis das 10.000-fache oder so an Laufzeit und Ressourcen.

Mal völlig abgesehen davon, dass du die Zahl der Abhängigkeiten deiner Software wegen so einem Kleinkram nicht erhöhen solltest.

Wenn du nicht wichtige Aspekte verschwiegen hast, kann ich nur zu dem Schluss kommen, dass das, worüber du gerade nachdenkst, für das Projekt eher nachteilig ist.

Geändert von mermshaus (15.03.2012 um 16:41 Uhr) Grund: „Hardware-Setup“ durch „Setup“ ersetzt. Geht ja doch eher um Software.
Mit Zitat antworten
  #8 (permalink)  
Alt 15.03.2012, 16:27
Erfahrener Benutzer
XHTMLforum-Mitglied
Thread-Ersteller
 
Registriert seit: 09.10.2010
Beiträge: 151
MitjaStachowiak befindet sich auf einem aufstrebenden Ast
Standard

Ok, wenn das mit den Dateien nicht so arg ins Gewicht fällt, werde ich das mal so lassen. Ihr müsst wissen, dass ich mehr aus der Anwendungsprogrammierung komme, also Pascal, Windows, DirectX und was nicht alles dazu gehört. Da geht es dann schon darum, möglichst effizient die unterschiedlichen Speicher zu nutzen.
Soweit ich weiß, gab es wegen diesem Projekt schon Ärger mit dem Hoster: Am Anfang hatten die eine SSH-Verbingung, über welche ein Perl-Script aufgerufen wurde, das die Daten dann in eine Datenbank geschrieben hat. Das soll angeblich zu Performanceproblemen geführt haben... Die Verbindung zur Datenbank musste mit jedem Request neu aufgebaut werden, glaub' ich. Demnächst soll die Archivierung in der Datenbank ja wieder flott gemacht werden: Wenn ich da die Standard-Perl-Befehle nutze und einfach mit jedem Request alle 10 Sekunden in die Datenbank schreibe, meint ihr, das ist mit der Serverauslastung vereinbar?
Mit Zitat antworten
  #9 (permalink)  
Alt 15.03.2012, 17:22
Erfahrener Benutzer
XHTMLforum-Mitglied
 
Registriert seit: 13.07.2006
Beiträge: 415
Maxefix ist ein sehr geschätzer MenschMaxefix ist ein sehr geschätzer MenschMaxefix ist ein sehr geschätzer Mensch
Standard

Prinzipiell sollte ein Datenbankserver alle 10s einen INSERT locker wegstecken. Aber da wir nicht wissen was du in die Datenbank schreibst (sprich wie viele Daten es sind), was sonst noch auf dem Server läuft und was für ne Hardware es genau ist, kann man da natürlich keine genaue Aussage treffen. Aber probiers doch aus und beobacht das ganze am Anfang noch etwas, um bei Problemen eingreifen zu können...

Zu den dauernden Zugriffen auf die Festplatte: Dafür ist sie da. Moderne Betriebssysteme haben sowieso einen guten IO-Scheduler, der die Last ordentlich verteilt. Somit kommt bei so kleinen Datenmengen sicherlich nichts ins stocken.

Du kannst aber die Sessions auch in den Arbeitsspeicher legen, z.B. über eine Ram-Disk oder eine MySQL-Datenbank mit einer MEMORY-Table. Oder du nutzt wie schon vorgeschlagen einen Shared-Memory-Cache a la APC. Aber das würde ich auch nur machen, wenn es wirklich Performance-Probleme wegen zu hoher IO-Last gibt... Ansonsten wäre das mit Kanonen auf Spatzen geschossen.

Gruß,
Max
Mit Zitat antworten
Sponsored Links
  #10 (permalink)  
Alt 15.03.2012, 17:44
Erfahrener Benutzer
XHTMLforum-Mitglied
 
Registriert seit: 13.07.2006
Beiträge: 747
mermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblickmermshaus ist ein wunderbarer Anblick
Standard

Wenn einige Male pro Minute ein paar Byte aus einer Datei gelesen und in sie geschrieben werden, zuckt der Server nicht mal mit der Wimper. Auf der Grundlage habe ich geantwortet.

Zitat:
Da geht es dann schon darum, möglichst effizient die unterschiedlichen Speicher zu nutzen.
Ja, klar. Aber das ist in der Programmierung ohnehin ein ewiges Thema. Maximale Effizienz erreichst du theoretisch wohl nur in Maschinencode und dort auch nur mit super schlauen, exakt angepassten Algorithmen.

So arbeitet natürlich niemand. Wir packen Abstraktionsschicht um Abstraktionsschicht drauf, fassen zusammen, finden allgemeine Lösungen, schreiben Makros, kapseln in Funktionen und Methoden und Modulen und nutzen Objektorientierung oder andere Formen der von einer konkreten Implementation in Maschinencode sehr weit entfernten Programmierung. Genial genug, wahrhaft effiziente Datenstrukturen oder Designmuster zu nutzen, sind wir vermutlich auch alle nicht.

Das kostet alles einen unglaublichen Haufen an Rechenzeit, macht dafür aber den Code überhaupt beherrschbar und verhältnismäßig leicht zu erstellen.

Ich finde das Argument deshalb immer schwierig, „willkürlich“ einen Aspekt eines Programms optimieren zu wollen, mit der Begründung, dass man grundsätzlich überall hinsichtlich der Laufzeit möglichst effizient programmieren sollte.

Das stimmt zwar irgendwie, aber die Chancen stehen gut, dass allein durch die Wahl der Sprache und der Bibliotheken und der Programmiertechniken „Ineffizienz“ in einer weitaus gewichtigeren Größenordnung in das Programm einfließt. Darauf sollte mein Vergleich mit dem Fahrrad abzielen.

Selbst wenn du „retten, was zu retten ist“ sagst, wäre die nächste Überlegung, ob du mit einer bestimmten Anpassung einen signifikanten Performancegewinn erzielen kannst, der einerseits die Entwicklungszeit rechtfertigt und der andererseits die Wahl der Mittel rechtfertigt, weil eventuell das Setup komplexer wird. (In diesem Fall möglicherweise durch das Hinzufügen einer PHP-Extension.)

Es gibt eben immer die beiden „Strömungen“, den Code schnell aber andererseits auch einfach zu halten. Das ist ein ewiges Abwägen.

Deshalb empfehle ich immer, bei solchen Fragen zuerst zu ermitteln, ob du überhaupt ein Laufzeitproblem hast und dann, ob der zu optimierende Code überhaupt eine inakzeptabel lange Laufzeit hat.

Bei einem simplen Dateizugriff würde ich das ausschließen.

„Premature optimization“ wäre noch ein Stichwort dazu:

- Program optimization - Wikipedia, the free encyclopedia

Geändert von mermshaus (15.03.2012 um 17:47 Uhr)
Mit Zitat antworten
Sponsored Links
Antwort

Stichwörter
fastcgi, perl, php, request, variable, weitergeben

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus


Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Problem mit globaler Variable onkel-tom Javascript & Ajax 9 13.03.2009 11:36
Problem mit http request onkel-tom Javascript & Ajax 43 05.03.2009 13:00
variable wird nicht richtig übergeben tichy Javascript & Ajax 4 15.11.2008 15:47
error_reporting(E_ALL); paracelsus Serveradministration und serverseitige Scripte 37 05.06.2008 08:36
global Variable wird nicht angezeigt ... paracelsus Serveradministration und serverseitige Scripte 14 09.10.2007 10:34


Alle Zeitangaben in WEZ +2. Es ist jetzt 20:53 Uhr.