tag:forum.selfhtml.org,2005:/self permanenter Zugriff auf Daten aus Datenbank? – SELFHTML-Forum 2018-12-18T17:33:24Z https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738397#m1738397 MB 2018-12-13T11:09:24Z 2018-12-13T11:09:24Z permanenter Zugriff auf Daten aus Datenbank? <p>moin,</p> <p>ich möchte einen permantenten Zugriff auf die Daten die aus der Datenbank Tabellen kommen <em>(z.B. Artikel, Benutzer (und plural) etc.)</em> haben, sodass ich nicht jedesmal eine Verbindung zur Datenbank für nur einen <em>HTTP</em>-Aufruf auf und abbauen muss. Ich verwende provisorisch Klassen <em>(z.B. ArticleStore)</em> die das zugehörige <em>Model</em> aus dem <em>Repository</em> übergeben und als <em>Property</em> für jeden <em>HTTP</em>-Aufruf abspeichern. Natürlich kann ich das auch Cashen, aber das wird dann doch zu umständlich, wenn man die Daten nur für einen <em>HTTP</em>-Aufruf benötigt.</p> <p>lgmb</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738403#m1738403 bobby 2018-12-13T11:23:19Z 2018-12-13T11:23:19Z permanenter Zugriff auf Daten aus Datenbank? <p>Moin,</p> <p>Dann wirst du irgend eine Zwischenschicht einbauen müssen, die die Datenbankverbindung offen hält und die entsprechenden Anfragen weiterleitet und das Ergebnis an den Webserver zurückgibt.</p> <p>m.E. würde das z.B. mit node.js gehen. Da kannst du Verbindungen zur DB offen halten und nur die entsprechenden Anfragen ausführen lassen und das Ergebnis z.B. als json z.B. an PHP zurückgeben lassen, welches dann das View erzeugt und per HTTP liefert.</p> <p>Gruß Bobby</p> <div class="signature">-- <br> -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <- ### Henry L. Mencken ### -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <- ### Viktor Frankl ### ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:) </div> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738409#m1738409 1unitedpower 2018-12-13T12:05:56Z 2018-12-13T12:05:56Z permanenter Zugriff auf Daten aus Datenbank? <blockquote> <p>ich möchte einen permantenten Zugriff auf die Daten die aus der Datenbank Tabellen kommen <em>(z.B. Artikel, Benutzer (und plural) etc.)</em> haben, sodass ich nicht jedesmal eine Verbindung zur Datenbank für nur einen <em>HTTP</em>-Aufruf auf und abbauen muss.</p> </blockquote> <p>Dein Stichwort lautet "Peristent Connection".</p> <ul> <li><a href="http://php.net/manual/en/features.persistent-connections.php" rel="noopener noreferrer">http://php.net/manual/en/features.persistent-connections.php</a></li> <li><a href="http://php.net/manual/en/pdo.connections.php" rel="noopener noreferrer">http://php.net/manual/en/pdo.connections.php</a></li> </ul> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738422#m1738422 MB 2018-12-13T12:41:12Z 2018-12-13T12:41:12Z permanenter Zugriff auf Daten aus Datenbank? <p>moin,</p> <blockquote> <p>Dann wirst du irgend eine Zwischenschicht einbauen müssen, die die Datenbankverbindung offen hält und die entsprechenden Anfragen weiterleitet und das Ergebnis an den Webserver zurückgibt.</p> </blockquote> <p>Ich will eben grade vermeiden das eine geöffnete Datenbank Verbindung entsteht. Das raushohlen was von der <em>App</em> temporär angefordert ist, dann in Klassen - wie du sagtest: <em>Zwischenschicht</em> - abspeichern und wahlweise drauf zugreifen z.B. <em>article</em>-Inhalt und <em>article</em>-Titel in unterschiedlichen Views. Da muss man zwei mal den Zugriff auf die Datenbank anstellen. Mit dieser <em>Zwischenschicht</em> habe ich das vermieden. Ich weis nicht ob ich dieses Daten im <em>Repository::property</em> abspeichern sollte oder eben eine <em>Zwischenschicht</em> Lösung ist.</p> <blockquote> <p>m.E. würde das z.B. mit node.js gehen.</p> </blockquote> <p>Ich verwende <em>PDO</em></p> <p>lgmb</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738413#m1738413 bobby 2018-12-13T12:15:11Z 2018-12-13T12:15:11Z permanenter Zugriff auf Daten aus Datenbank? <p>Moin,</p> <p>Bei persistenten Verbindungen wird geschaut ob eine identische Verbindung besteht.</p> <p>Ich muss trotzdem jedes mal den Datenbankserver nach der Verbindung fragen. Das entfällt bei Nutzung einer Zwischenschicht wie z.B. node.JS.</p> <p>Gruß Bobby</p> <div class="signature">-- <br> -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <- ### Henry L. Mencken ### -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <- ### Viktor Frankl ### ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:) </div> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738418#m1738418 dedlfix 2018-12-13T12:33:50Z 2018-12-13T12:33:50Z permanenter Zugriff auf Daten aus Datenbank? <p>Tach!</p> <blockquote> <p>Bei persistenten Verbindungen wird geschaut ob eine identische Verbindung besteht.</p> <p>Ich muss trotzdem jedes mal den Datenbankserver nach der Verbindung fragen.</p> </blockquote> <p>Mit anderen Worten: Das spart keinerlei Code. Es kommt sogar noch hinzu, dass man das Persistenzattribut angeben muss. Und dass das ganze sowieso nur funktioniert, wenn PHP als Modul im Apachen läuft (IIS und andere Webserver nicht betrachtend). Im Modul zu laufen, hat Nachteile in Webservern, in denen mehr als die eine Anwendung laufen soll, wie schlechte oder keine Separierbarkeit.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738419#m1738419 1unitedpower 2018-12-13T12:34:31Z 2018-12-13T12:34:31Z permanenter Zugriff auf Daten aus Datenbank? <blockquote> <p>Bei persistenten Verbindungen wird geschaut ob eine identische Verbindung besteht.</p> </blockquote> <p>Das muss ja auch so sein. Identisch heißt, dass Server, Nutzer und Passwort übereinstimmen müssen. Es wäre ja ein Bug, wenn ich eine Verbindung <code>max:passwort@127.0.0.1:3306</code> haben möchte, aber stattdessen eien Verbindung <code>root:geheim@127.0.42:3306</code> bekomme. Das müsste ein Service mit Node also auch sicherstellen.</p> <blockquote> <p>Ich muss trotzdem jedes mal den Datenbankserver nach der Verbindung fragen.</p> </blockquote> <p>Nein, die Verbindung wird vom Webserver gespeichert und offen gehalten. Der Datenbankserver muss nicht erneut angefragt werden. Das wäre auch ein seltsamer Zirkelschluss, um eine Verbindung vom Datenbankserver zu bekommen, müsste ich ihn erstmal fragen, also müsste ich schon eine Verbindung haben.</p> <blockquote> <p>Das entfällt bei Nutzung einer Zwischenschicht wie z.B. node.JS.</p> </blockquote> <p>Für den Vorschlag mit Node hab ich dir auch ein Sternchen gegeben. Konzeptionell hast du aber ein ähnliches Problem: Jetzt muss sich jeder PHP-Prozess mit dem Node-Service verbinden. Ich glaube trotzdem, dass das effizienter seien kann als sich erneut mit dem DB-Server zu verbinden. Inbesondere wenn Node und PHP auf dem selben physischen Server laufen, die Datenbank aber woanders.</p> <p>Die PHP Lösung scheint mir trotzdem einfacher.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738427#m1738427 1unitedpower 2018-12-13T12:46:00Z 2018-12-13T12:49:06Z permanenter Zugriff auf Daten aus Datenbank? <blockquote> <blockquote> <p>Ich muss trotzdem jedes mal den Datenbankserver nach der Verbindung fragen.</p> </blockquote> <p>Mit anderen Worten: Das spart keinerlei Code. Es kommt sogar noch hinzu, dass man das Persistenzattribut angeben muss.</p> </blockquote> <p>Ich glaube, es ging MB nicht darum Code zu sparen, sondern die Effizienz zu steigern. Das eine Attribut mehr scheint mir für die geforderte Funktionalität die Lösung mit dem wenigsten Code zu sein. Oder hast du noch eine andere Idee, die mit weniger auskommt?</p> <blockquote> <p>Und dass das ganze sowieso nur funktioniert, wenn PHP als Modul im Apachen läuft (IIS und andere Webserver nicht betrachtend). Im Modul zu laufen, hat Nachteile in Webservern, in denen mehr als die eine Anwendung laufen soll, wie schlechte oder keine Separierbarkeit.</p> </blockquote> <p>Bist du da sicher? Das Handbuch sagt etwas anderes. Nur PHP als CGI scheint ein Problem zu sein, aber hat das heutzutage noch Relevanz?</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738577#m1738577 ursus contionabundo 2018-12-15T10:27:21Z 2018-12-15T10:45:53Z permanenter Zugriff auf Daten aus Datenbank? <blockquote> <p>Die PHP Lösung scheint mir trotzdem einfacher.</p> </blockquote> <p>Ich würde auch dabei bleiben wollen. Die Verfügbarkeit von <a href="https://www.npmjs.com/package/http-server" rel="nofollow noopener noreferrer">Node-Js</a> oder auch der Möglichkeit, mit <a href="https://docs.python.org/3/library/http.server.html#http.server.HTTPServer" rel="nofollow noopener noreferrer">Python</a> oder <a href="http://php.net/manual/de/features.commandline.webserver.php" rel="noopener noreferrer">PHP</a> kleine "Serviceserver" zu installieren, ist nämlich begrenzt. Einmal schon durch die PIDs und dann die Ports. Beim Shared Hosting sind nämlich mitunter die Webseiten tausender Kunden auf einem Server. Und wenn die jetzt anfangen, wie die Weltmeister solche "Serviceworker" zu starten, dann werden je nach Konfiguration zuerst entweder die PID oder die Ports knapp.</p> <p>Außerdem muss dann (shared hosting) beim Zugriff eine Authorisierung stattfinden. Die wird so teuer, dass der Geschwindigkeitsgewinn sehr negativ ist.</p> <p>Auf einem eigenen Server kann man natürlich tun und lassen was man will. Jedenfalls bis der Access-Provider an seiner Firewall fummelt weil zu viele Beschwerden über Spamversand oder Hackversuche bei seinem abuse auflaufen…</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738441#m1738441 bobby 2018-12-13T14:53:30Z 2018-12-13T14:53:30Z permanenter Zugriff auf Daten aus Datenbank? <p>Moin,</p> <p>Dann hatte ich dich falsch verstanden... warum willst du denn nicht eine Verbindung offen halten? Datenbanken sind dazu da Daten vorzuhalten. Wenn du diese jetzt nochmal extra cachest, erschließt sich mir nicht ganz der Sinn dahinter. Könntest du deine Gedanken dazu noch etwas weiter ausführen, sodass man evtl. deine Intension dahinter erkennen kann?</p> <p>Gruß Bobby</p> <div class="signature">-- <br> -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <- ### Henry L. Mencken ### -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <- ### Viktor Frankl ### ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:) </div> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738434#m1738434 dedlfix 2018-12-13T13:03:09Z 2018-12-13T13:03:09Z permanenter Zugriff auf Daten aus Datenbank? <p>Tach!</p> <blockquote> <blockquote> <blockquote> <p>Ich muss trotzdem jedes mal den Datenbankserver nach der Verbindung fragen.</p> </blockquote> <p>Mit anderen Worten: Das spart keinerlei Code. Es kommt sogar noch hinzu, dass man das Persistenzattribut angeben muss.</p> </blockquote> <p>Ich glaube, es ging MB nicht darum Code zu sparen, sondern die Effizienz zu steigern. Das eine Attribut mehr scheint mir für die geforderte Funktionalität die Lösung mit dem wenigsten Code zu sein. Oder hast du noch eine andere Idee, die mit weniger auskommt?</p> </blockquote> <p>Der Verbindungsaufbau ist vernachlässigbar, wenn nicht gerade eine sehr langsame Netzwerkverbindung zwischen Webserver und DBMS besteht. Da lässt sich durch Netzwerkoptimierung mehr sparen. Zumal ein langsames Netzwerk ja auch auf Query- und Ergebnisübertragung wirkt.</p> <blockquote> <blockquote> <p>Und dass das ganze sowieso nur funktioniert, wenn PHP als Modul im Apachen läuft (IIS und andere Webserver nicht betrachtend). Im Modul zu laufen, hat Nachteile in Webservern, in denen mehr als die eine Anwendung laufen soll, wie schlechte oder keine Separierbarkeit.</p> </blockquote> <p>Bist du da sicher? Das Handbuch sagt etwas anderes. Nur PHP als CGI scheint ein Problem zu sein, aber hat das heutzutage noch Relevanz?</p> </blockquote> <p>Bei CGI wird für jeden Request ein Prozess gestartet und beendet. Da gibts nichts, was eine DBMS-Verbindung offenhalten könnte.</p> <p>Bei den Formen FCGI und FPM fehlt mir das Wissen, wie lange der Prozess bestehen bleibt und damit auch evenuell geöffnete Verbindungen. Da in diesen Szenarien mehrere PHP-Instanzen nebeneinander laufen, muss dann aber auch jede eigene ihre eigenen Verbindungen verwalten. Das hat dann keinen Effekt wenn der nächste Request an einen anderen Prozess im Pool geht, der die Verbindung noch nicht geöffnet hat. Es sei denn, die Verwaltung der Verbindungen kann von der Poolverwaltung übernommen werden. Da die Vorteile persistenter Verbindungen aber nicht wirklich merkbar sind, hab ich mich damit nicht weiter beschäftigt.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738572#m1738572 ursus contionabundo 2018-12-15T09:15:10Z 2018-12-15T09:15:53Z Shared Hosting <blockquote> <p>Nur PHP als CGI scheint ein Problem zu sein, aber hat das heutzutage noch Relevanz?</p> </blockquote> <p>In Umgebungen, in denen die <a href="https://httpd.apache.org/docs/2.4/mod/mod_suexec.html" rel="nofollow noopener noreferrer">PHP-Skripte mit Rechten eines per Hostnamen konfigurierbaren Nutzers</a> ausgeführt werden (shared hosting) hat PHP als CGI durchaus Relevanz.</p> <p>Und das sind verdammt viele...</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738476#m1738476 MB 2018-12-14T00:27:03Z 2018-12-14T00:27:03Z permanenter Zugriff auf Daten aus Datenbank? <p>moin,</p> <blockquote> <p>Dann hatte ich dich falsch verstanden...</p> </blockquote> <p>Kein problem. Ich drück mich wirklich in dem Forum sehr undeutlich aus .</p> <blockquote> <p>warum willst du denn nicht eine Verbindung offen halten?</p> </blockquote> <p>ich hätte gern alles drin oder draußen. Sprich: je nach URL-Route holt sich die App die angeforderten Daten aus der Datenbank raus und speichert sie dann in zur Laufzeit bereitstehenden Klassen. Da alle informationen jetzt zur Laufzeit in der App enthalten sind, können sich jetzt View-Templates mit diesen gespeicherten Daten befüllen lassen.</p> <blockquote> <p>Datenbanken sind dazu da Daten vorzuhalten. Wenn du diese jetzt nochmal extra cachest, erschließt sich mir nicht ganz der Sinn dahinter.</p> </blockquote> <p>Ich sehe Datenbank und PHP-Application als zwei Einheiten an und es ist nicht immer gegeben das Datenbank + App auf dem selben Server liegen. Außerdem habe ich das gefühldas ich ein wenig unter <a href="https://en.wikipedia.org/wiki/Obsessive%E2%80%93compulsive_disorder" rel="nofollow noopener noreferrer">OCD</a> leide - <em>wird noch geprüft</em>.</p> <p>lgmb</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738602#m1738602 pl 2018-12-15T13:13:58Z 2018-12-15T13:13:58Z permanenter Zugriff auf Daten aus Datenbank? <p>moin,</p> <blockquote> <blockquote> <p>Dann hatte ich dich falsch verstanden...</p> </blockquote> <p>Kein problem. Ich drück mich wirklich in dem Forum sehr undeutlich aus .</p> <blockquote> <p>warum willst du denn nicht eine Verbindung offen halten?</p> </blockquote> <p>ich hätte gern alles drin oder draußen. Sprich: je nach URL-Route holt sich die App die angeforderten Daten aus der Datenbank raus und speichert sie dann in zur Laufzeit bereitstehenden Klassen.</p> </blockquote> <p>Eine solche Anforderung spricht mehr für mod_php. Dafür ist eine persistente DB Verbindung gar nicht notwendig, es genügt ja, die Daten beim Starten des Webservers in den Speicher zu laden. Wobei das auch sukzessive erfolgen kann: Bspw. so, daß das Template nur beim 1. Request auf einen URL geladen wird und bei allen weiteren Requests bereits im Hauptspeicher vorliegt.</p> <blockquote> <p>Da alle informationen jetzt zur Laufzeit in der App enthalten sind, können sich jetzt View-Templates mit diesen gespeicherten Daten befüllen lassen.</p> </blockquote> <p>Genau. Alternative zu mod_php ist fast_cgi, damit ließe sich das auch machen.</p> <blockquote> <blockquote> <p>Datenbanken sind dazu da Daten vorzuhalten. Wenn du diese jetzt nochmal extra cachest, erschließt sich mir nicht ganz der Sinn dahinter.</p> </blockquote> </blockquote> <p>Ganz einfach: Die Performance.</p> <blockquote> <p>Ich sehe Datenbank und PHP-Application als zwei Einheiten an und es ist nicht immer gegeben das Datenbank + App auf dem selben Server liegen.</p> </blockquote> <p>Ist auch gar nicht notwendig. Dem Webserver ist das völig wurst woher der seine Daten kriegt. Aber ein Benutzer freut sich, wenn sie bereits im Hauptspeicher liegen, denn das merkt er sehr deutlich!</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738573#m1738573 dedlfix 2018-12-15T09:18:49Z 2018-12-15T09:18:49Z permanenter Zugriff auf Daten aus Datenbank? <p>Tach!</p> <blockquote> <blockquote> <p>Nur PHP als CGI scheint ein Problem zu sein, aber hat das heutzutage noch Relevanz?</p> </blockquote> <p>In Umgebungen, in denen die PHP-Skripte mit Rechten eines per Hostnamen konfigurierbaren Nutzers ausgeführt werden (shared hosting) hat PHP als CGI durchaus Relevanz.</p> </blockquote> <p>Für nackiges CGI ist das keine Frage, aber wie genau verhält es sich bei FCGI und FPM? Da beide die Nachteile der langsamen Geschwindigkeit von CGI ausgleichen sind die ja eher relevant.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738575#m1738575 ursus contionabundo 2018-12-15T10:14:16Z 2018-12-15T10:15:55Z permanenter Zugriff auf Daten aus Datenbank? <p><a href="https://christophfischer.com/linux/12-apache/47-apache-server-mit-php-fastcgi-und-debian-50-lenny" rel="nofollow noopener noreferrer">Christoph Fischer hat eine kleine php-fcgid-Dok geschrieben</a>.</p> <p>Demnach überleben fcgid-Prozesse eine konfigurierbare Weile (z.B. 500 Requests oder 300 Sekunden Untätigkeit + "IdleScanInterval 30") - und ja: Auch hier ist der Benutzer und die Gruppe konfigurierbar. Mein Hoster (einer der besseren) benutzt es fürs Shared Hosting.</p> <p>Die persistente Datenbankverbindung lebt maximal so lange wie der fcgid-Prozess. Das hilft also schon ...</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738583#m1738583 ursus contionabundo 2018-12-15T10:51:48Z 2018-12-15T10:51:48Z Sicherheit: Webdienste mt php, node.js oder python auf localhost und shared hosting <blockquote> <p>Außerdem muss dann (shared hosting) beim Zugriff eine Authorisierung stattfinden. Die wird so teuer, dass der Geschwindigkeitsgewinn sehr negativ ist.</p> </blockquote> <p>Oh. Und diese Verbindung ist, weil unverschlüsselt, von anderen Benutzern womöglich (z.B. tcpdump braucht er schon noch) belauschbar.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738598#m1738598 1unitedpower 2018-12-15T12:45:06Z 2018-12-15T12:45:06Z Sicherheit: Webdienste mt php, node.js oder python auf localhost und shared hosting <blockquote> <blockquote> <p>Außerdem muss dann (shared hosting) beim Zugriff eine Authorisierung stattfinden. Die wird so teuer, dass der Geschwindigkeitsgewinn sehr negativ ist.</p> </blockquote> <p>Oh. Und diese Verbindung ist, weil unverschlüsselt, von anderen Benutzern womöglich (z.B. tcpdump braucht er schon noch) belauschbar.</p> </blockquote> <p>AFAIK benutzen Shared Hoster Sandboxing um Kundendaten voneinander zu isolieren. Zum Beispiel den <a href="https://en.wikipedia.org/wiki/User-mode_Linux" rel="nofollow noopener noreferrer">User-mode</a>. Damit lassen sich auch die Kommunikation zwischen Prozessen via Unix-Sockets und die Netzwerk-Kommunikation mittels TCP regulieren. Da bleibt natürlich trotzdem noch Luft für Fehler seitens der Konfiguration. Wenn schon Zweifel bei der grundlegendenden Sicherheitsarchitektur eines Shared Hosters bestehen, dann sollte man da besser gar nicht erst hosten.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738616#m1738616 ursus contionabundo 2018-12-15T14:28:26Z 2018-12-15T14:30:22Z Sicherheit: Webdienste mt php, node.js oder python auf localhost und shared hosting <blockquote> <p>AFAIK benutzen Shared Hoster Sandboxing um Kundendaten voneinander zu isolieren.</p> </blockquote> <p>Meiner wohl nicht. Der Kernel meldet sich als Stino-Distributionskernel und ich sehe fremde Prozesse mit <code>ps -eLF</code>.</p> <p>Ich bin mir auch nicht ganz sicher wie das mit sehr vielen Benutzern und vor allem dem Webserver gehen soll. Hier geht es nicht um "Cloud".</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738604#m1738604 dedlfix 2018-12-15T13:25:03Z 2018-12-15T13:25:03Z permanenter Zugriff auf Daten aus Datenbank? <p>Tach!</p> <blockquote> <blockquote> <p>ich hätte gern alles drin oder draußen. Sprich: je nach URL-Route holt sich die App die angeforderten Daten aus der Datenbank raus und speichert sie dann in zur Laufzeit bereitstehenden Klassen.</p> </blockquote> <p>Eine solche Anforderung spricht mehr für mod_php. Dafür ist eine persistente DB Verbindung gar nicht notwendig, es genügt ja, die Daten beim Starten des Webservers in den Speicher zu laden.</p> </blockquote> <p>mod_php hat keinen Shared Memory. Die Requests laufen voneinander getrennt, und die Daten stehen nicht gemeinsam zur Verfügung.</p> <blockquote> <p>Genau. Alternative zu mod_php ist fast_cgi, damit ließe sich das auch machen.</p> </blockquote> <p>Mit FCGI und auch FPM geht das ebensowenig. Wenn man einen dauerhaften Cache haben möchte, muss man sich eines anderen Dienstes bemühen, beispielsweise memcached.</p> <p>Man mag sich damit Geschwindigkeit holen, aber bekommt nun eine Menge neue Aufgaben, diesen Cache parallel zur Datenbank zu verwalten.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738828#m1738828 MB 2018-12-18T00:12:22Z 2018-12-18T00:12:22Z permanenter Zugriff auf Daten aus Datenbank? <p>moin,</p> <blockquote> <p>Eine solche Anforderung spricht mehr für mod_php. [...]</p> </blockquote> <p>...und...</p> <blockquote> <p>[...] Alternative zu mod_php ist fast_cgi, damit ließe sich das auch machen.</p> </blockquote> <p>kann man das nicht per signifikanten User <em>Token</em> von der <code>$_SESSION</code>-gesteuert selber cachen? wie…</p> <pre><code class="block language-php"><span class="token keyword">class</span> <span class="token class-name-definition class-name">Cache</span> <span class="token punctuation">{</span> <span class="token keyword">private</span> <span class="token keyword">static</span> <span class="token variable">$_token</span><span class="token punctuation">;</span> <span class="token keyword">public</span> <span class="token keyword">static</span> <span class="token keyword">function</span> <span class="token function-definition function">init</span><span class="token punctuation">(</span> <span class="token keyword type-hint">string</span> <span class="token variable">$token</span> <span class="token punctuation">)</span> <span class="token punctuation">{</span> <span class="token keyword static-context">self</span><span class="token operator">::</span><span class="token variable">$_token</span> <span class="token operator">=</span> <span class="token variable">$token</span><span class="token punctuation">;</span> <span class="token punctuation">}</span> <span class="token keyword">public</span> <span class="token keyword">static</span> <span class="token keyword">function</span> <span class="token function-definition function">store</span><span class="token punctuation">(</span> <span class="token keyword type-hint">array</span> <span class="token variable">$data</span> <span class="token punctuation">)</span> <span class="token punctuation">:</span> <span class="token keyword return-type">bool</span> <span class="token punctuation">{</span> <span class="token comment">// schreibt die temporären daten serialisiert mit self::$_token in PATH Konstante</span> <span class="token punctuation">}</span> <span class="token keyword">public</span> <span class="token keyword">static</span> <span class="token keyword">function</span> <span class="token function-definition function">load</span><span class="token punctuation">(</span><span class="token punctuation">)</span> <span class="token punctuation">:</span> <span class="token keyword return-type">array</span> <span class="token punctuation">{</span> <span class="token comment">// prüft ob PATH Konstante existiert und der self::$_token angehängt ist</span> <span class="token comment">// dann öffnet und deserialöisiert die Klasse den Content und gibt ihn als array zurüch</span> <span class="token punctuation">}</span> <span class="token punctuation">}</span> </code></pre> <p>lgmb</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738958#m1738958 MB 2018-12-18T17:33:24Z 2018-12-18T17:33:24Z permanenter Zugriff auf Daten aus Datenbank? <p>moin,</p> <p>Ich mache mal nen neuen Thread auf mit dieser Frage</p> <p>lgmb</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738605#m1738605 pl 2018-12-15T13:35:59Z 2018-12-15T13:35:59Z permanenter Zugriff auf Daten aus Datenbank? <p>Memcache ist ein Protokoll was Daten systemübergreifend verfügbar macht. Das meinte ich nicht. Ich bin nur davon ausgegangen, daß mod_php ähnlich wie mod_perl funktioniert. Damit ist das nämlich machbar was ich beschrieben habe: Sämtliche Templates (u.a. statische Daten) beim Starten des Webservers in den Hauptspeicher zu legen.</p> <p>Und das heißt, daß man hierzu eine etwaige DB Verbindung eben nur beim Serverstart benötigt. Ebenfalls im Hauptspeicher verbleiben kompilierte Klassen und Methoden als sog. Bytecode. So jedenfalls arbeitet mod_perl, das ist ja das was mod_perl so schnell macht.</p> <p>MfG</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738609#m1738609 dedlfix 2018-12-15T13:49:24Z 2018-12-15T13:49:24Z permanenter Zugriff auf Daten aus Datenbank? <p>Tach!</p> <blockquote> <p>Memcache ist ein Protokoll was Daten systemübergreifend verfügbar macht.</p> </blockquote> <p>memcached mit d am Ende ist kein Protokoll und Daten verfügbar machen kann nur eine Software. Genau das ist memcached, ein Service, der (vorzugsweise) lokal auf dem Server läuft.</p> <p>dedlfix.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738611#m1738611 pl 2018-12-15T13:59:17Z 2018-12-15T13:59:17Z permanenter Zugriff auf Daten aus Datenbank? <p>Tach!</p> <blockquote> <blockquote> <p>Memcache ist ein Protokoll was Daten systemübergreifend verfügbar macht.</p> </blockquote> <p>memcached mit d am Ende ist kein Protokoll und Daten verfügbar machen kann nur eine Software. Genau das ist memcached, ein Service, der (vorzugsweise) lokal auf dem Server läuft.</p> </blockquote> <p>Nochmal: Ich meinte weder das Eine noch das Andere!</p> <p>.</p> https://forum.selfhtml.org/self/2018/dec/13/permanenter-zugriff-auf-daten-aus-datenbank/1738614#m1738614 Matthias Apsel matthias.apsel@selfhtml.org https://brückentage.info 2018-12-15T14:06:51Z 2018-12-15T14:06:51Z permanenter Zugriff auf Daten aus Datenbank? <p>Hallo pl,</p> <blockquote> <p>Nochmal: Ich meinte weder das Eine noch das Andere!</p> </blockquote> <p>Dann solltest du dich vielleicht besser verständlich machen.</p> <p>Bis demnächst<br> Matthias</p> <div class="signature">-- <br> Pantoffeltierchen haben keine Hobbys. </div>