|
|||
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). |
Sponsored Links |
|
|||
Zitat:
|
Sponsored Links |
|
|||
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 |
|
|||
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) |
|
||||
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. |
|
|||
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. |
|
|||
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? |
|
|||
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 |
Sponsored Links |
|
|||
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:
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) |
Sponsored Links |
Stichwörter |
fastcgi, perl, php, request, variable, weitergeben |
Themen-Optionen | |
Ansicht | |
|
|
Ä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 |