Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Dann lieber https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-node.html als Vergleich hernehmen. Neuste Versionen, open source. Da ist nodejs bis auf 2 Ausnahmen entweder ähnlich schnell oder deutlich schneller. Und wenn man bei nodejs dazu noch das worker Modul nutzt, um wie bei php auch mehrere Prozesse zu haben, wird nodejs Kreise um php ziehen, was es ja auch ohne schon teilweise tut.
Dafür leider ein komplett veraltetes System, wodurch u.a. Cache-Optimierungen in der CPU nicht genutzt werden können... (Intel Q6600).
Um ehrlich zu sein ist das doch auch alles ziemlich "Bums". Für transaktionslastigen Kram mit viel Logik nimmt man PHP (oder was anderes, Java, ...), für real time Module und large content delivery node.js. Und beides kann man prima kombinieren, was auch oft genug getan wird.
Wird bei Millionen von Views ohnehin notwendig werden über Content Delivery Networks, Microservices und Load Balancer nachzudenken.
Und wenn die Anwendung geplant niemals Millionen von Views haben soll, dann kann man sich den ganzen Performance-Budenzauber eh sparen, weil man dann mit "mehr RAM", "mehr CPU", "mehr Worker Threads", "mehr Opcache", "mehr I/O" alles viel besser und leichter "via Config" performance tunen kann.
Dann lieber https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-node.html als Vergleich hernehmen. Neuste Versionen, open source. Da ist nodejs bis auf 2 Ausnahmen entweder ähnlich schnell oder deutlich schneller. Und wenn man bei nodejs dazu noch das worker Modul nutzt, um wie bei php auch mehrere Prozesse zu haben, wird nodejs Kreise um php ziehen, was es ja auch ohne schon teilweise tut.
Du vergleichst hier die Geschwindigkeit von 2 „Programmiersprachen“, was falsch ist. NodeJS ist Eventdriven und Asynchron, während PHP bei jedem Request sequentell neuausgeführt wird. Du hast weder PHP noch NodeJS verstanden. Der Benchmark ist 0 Aussagekräftig.
Wenn dann vergleicht man hier eher die Laufzeitumgebungen. JavaScript an sich hat erstmal nix mit der Event-Loop und dem drumherum zu tun. Und das ist tatsächlich auch ein entscheidener Punkt, da es andere JavaScript Engines gibt, die nicht Ansatzweise an die Performance der V8 rankommen. Bei PHP könnte man auch HHVM nutzen, zumindest vor PHP 7.0 hatte das teilweise eine deutlich bessere Performance.
Und warum sollte man das nicht vergleichen können? Man kann mit beidem das gleiche erreichen, nur halt mit anderen "Grundsätzen". Wenn diese unterschiedlichen Grundsätze in unterschiedlicher Performance enden, sind die aber sehr wohl relevant für mich. Wo ist das Problem dabei? Darf ich auch nicht PHP mit ASP.NET vergleichen, wenn ich mich erkundige, womit ich die nächste Website entwickeln kann?
Mit PHP habe ich tatsächlich noch keine einzige Zeile entwickelt, die produktiv im Einsatz ist. U.a. mit Node.js dagegen verdiene ich mein Brot. Und die Software die ich damit entwickle ist Weltweit im Einsatz. Ich bin mir nicht sicher, ob sie das bei einem der größten Unternehmen Deutschlands sein würde, wenn ich Node.js nicht könnte. Aber das ist nun wirklich absolut off-topic.
Die suche ich gar nicht. Stattdessen habe ich gar eine noch einfachere Lösung als deine mit den Symlinks aufgezeigt.
Das ist mehr als nur EINEN Symlink einfach anlegen. Spiegelung (und synchron halten dieser - "Angemeldet bleiben"), Sessionhandling und aufräumen. Aber das hast du ja schon selbst gesagt:
Also so wie ers beschrieben hat gibts EINEN internen Bereich, nicht für jede Session einen, entsprechend leg ich da EINEN Symlink auf das Verzeichnis an und fertig ist der Lack.
Ich weiß ja nicht ob du sowas schon gemacht hast und das deine Erfahrung ist oder du das nur vermutest, aber wenn du deine Applikation mit nur 50 Datenbankabfragen in den Keller schießt, machst du irgendwas falsch. Spätestens wenn man bspw. Redis mit im Einsatz hat und das geschickt einsetzt sind eine halbe Million requests pro Sekunde (auf einem einzigen Server und einem einzigen Kern) kein Problem, zumindest nicht für die Datenbank - und wenn man nicht an die obere Grenze geht, das ganze auch bei Latenzen unter einer Millisekunde. Und 50 für Abfragen für einen Seitenaufbau stellen auch für eine ganz simple MariaDB keinerlei ein Problem dar, außer Indizes etc. sind ein Fremdwort für dich und LIKE deine Lieblingsbedingung.
In meiner Welt gibts 200 User die auf eine Webanwendung zugreifen und entsprechend sind Server usw ausgelegt, auf der andern Seite bringts bei mir auch nicht so viel zu cachen weil da 90% Bewegungsdaten sind die sich eh alle 3 Requests ändern, das ist halt wirklich Webanwendung und nicht ne bessere Website wo sich alle Nase lang mal ein neuer Post ins Wordpress schleicht oder so. Von daher cache ich da stehende Daten eher bei jedem Request als in der Session oder über Drittmittel, allein weil es fatal wäre wenn ich irgendwo was auf Basis gecachter Daten berechne und die Infos veraltet sind.
Ich hab die Anwendung halt auch bei X Kunden laufen und die setzen ihre DB selber auf, entsprechend kannst du jetzt raten wie oft ich, gerade bei MariaDb, schon Statements vor den Baum hab laufen sehen weil 32Mb Ram je Abfrage eingestellt waren und sone Scherze. Also MariaDb/MySql sind so Kandidaten wo du mit der Standardconfig totsicher ins Swapping läufst und da kannst du dann die Daten fast tröpfeln hören, da hat man mit Mssql oder Oracle deutlich weniger zu schaffen. Da gehts nichtmal um Like oder Indices sondern wirklich um Statements mit teils einfachen Joins (where in ohne exists ist auch son Kandidat).
Aber genug aus meiner persönlichen Hölle: so oder so gibts (wenn du nicht cachen kannst/willst) nix teureres als ne DB Abfrage, rechne mal allein die Latenz hin und her zum DB Server + die Verarbeitungszeit auf dem Server selbst und dann läuft das in Php eigentlich schön in der Reihe, entsprechend summiert sich das auf. Von daher überlege ich persönlich immer ob das was ist was zwingend in die Db muss oder ob man das nicht anders und schneller lösen kann... Was ein Rant, jetzt reichts aber wirklich
Also so wie ers beschrieben hat gibts EINEN internen Bereich, nicht für jede Session einen, entsprechend leg ich da EINEN Symlink auf das Verzeichnis an und fertig ist der Lack.
Dann musst du mir die Methode nochmal genauer erläutern, wie das damit funktionieren soll.
Ja, Datenbank ist das teuerste, aber wie viele Abfragen willst du denn machen, sodass sich da was großartig aufsummiert um zu wissen ob der User das Bild sehen darf oder nicht? Und nein, die Queries für die einzelnen Bilder laufen da eben nicht in Reihe, weil der Browser die parallel anfragt und jede halbwegs vernünftige Webserver bzw. FPM Konfigurationen dafür dann auch mehrere PHP-Interpreter parallel ausführt.
Du vergleichst hier die Geschwindigkeit von 2 „Programmiersprachen“, was falsch ist. NodeJS ist Eventdriven und Asynchron, während PHP bei jedem Request sequentell neuausgeführt wird. Du hast weder PHP noch NodeJS verstanden. Der Benchmark ist 0 Aussagekräftig.
Und du berechnest Fraktale mit Php? Benches sind gut und schön aber was macht man denn typischerweise mit beiden? Bissl Db, über Arrays rödeln, if und else und da hörts schon fast auf. Versteh mich nicht falsch, mit irgendwas muss man benchen, aber irgendwo ist das auch Kilometer an dem vorbei was wir da eigentlich mit den Sprachen tun. Ich will nicht ausschließen dass da auch jemand im großen Stil Fraktale und Co berechnet oder eben Binary Trees baut oder weiß der Geier, nur das Gros an Php Entwicklern wird wahrscheinlich 1000 foreach schreiben und 200 Db Abfragen eh sie einmal sowas anfassen, und da hört das dann irgendwie auf relevant zu sein wenn man nicht wirklich einen binary Tree mit drölftausend Knoten implementieren muss...
Ergänzung ()
Bagbag schrieb:
Dann musst du mir die Methode nochmal genauer erläutern, wie das damit funktionieren soll.
Ja, Datenbank ist das teuerste, aber wie viele Abfragen willst du denn machen, sodass sich da was großartig aufsummiert um zu wissen ob der User das Bild sehen darf oder nicht? Und nein, die Queries für die einzelnen Bilder laufen da eben nicht in Reihe, weil der Browser die parallel anfragt und jede halbwegs vernünftige Webserver bzw. FPM Konfigurationen dafür dann auch mehrere PHP-Interpreter parallel ausführt.
Na er sagte ein interner Bereich -> heisst für mich ein Verzeichnis in dem Bilder lagern (./picsintern) heisst wenn sich jemand anmeldet check ich gegen ob der Zugriff auf ./picsintern haben darf und werf nach ./piczugriff einen symlink mit Namen der SessionId auf den Ordner ./picsintern. Ausgabe ist dann nur noch ./piczugriff/SessionId/ auf Lesbarkeit prüfen und die Bilder normal durchrödeln und ausgeben, Thumbs kann man vorgeneriert da mitlagern. Eine Helferfunktion prüft bei jedem Request zur Anmeldung im Ordner /piczugriff nach abgelaufenen Sessions und löscht die abgelaufenen Symlinks.
Also lass mich jetzt nicht lügen aber das sollte in maximal 100 Zeilen Code abgehandelt sein, vier Db Abfragen um den Login zu checken, die SessionId in eine Tabelle mit gültigen Sessions zu werfen, ungültige Sessions aus der Tabelle löschen, gültige Sessions abholen, dann über den Ordner laufen und löschen was nicht gültig ist.
Ergänzung ()
Kanibal schrieb:
Interessant wäre noch, wie Du die Bilder per PHP durchreichst. Mit Output-Buffering oder ohne? readfile() oder file_get_contents()?
Bei der Methode mit den symlinks müsste man nur die Quelle ins Html legen mit src='picsintern/SessionId/bla.jpg', wenn ich das jetzt als blob ins Html schießen sollte wärs mir fast egal weil sich die 10kb für ein Thumb eigentlich wegscheißen, aber grundsätzlich würde ich bei sowas outputbuffering weglassen....
Achso: Headergeschichte: ist immer die Frage ob man das so konfigurieren kann, in meiner Anwendung würde ich das per se erstmal nicht nutzen weil der Apache das ohne Extramodul afaik gar nicht kann. Wenn ich jetzt ne eigene Geschichte laufen hab und selber das Hosting mache und den Apache laufen hab bzw Nginx dann ist das ne feine Sache, aber wenn ich für andere entwickle ist das wie ein Schuss ins Knie weil dir das garantiert um die Ohren fliegt. Ich hab noch Kunden auf Php 5.4 (!!!!), da muss ich dir jetzt nix groß erzählen wenn ich sage dass du bei denen betteln musst dass sie ihre mysql Config mal anpassen sollen oder auch nur die Php Ini. Wenn du solchen Kunden mit Apache Modulen kommst brauchst du 2 Jahre bis alle nachgezogen haben und dann knallts schon beim ersten der seinen Apache geupdated hat und das Modul vergessen hat.
Das ist immer so der kleine aber feine Unterschied Theorie/Praxis Self Hosting/Fremd Hosting.
Und du berechnest Fraktale mit Php? Benches sind gut und schön aber was macht man denn typischerweise mit beiden? Bissl Db, über Arrays rödeln, if und else und da hörts schon fast auf. Versteh mich nicht falsch, mit irgendwas muss man benchen, aber irgendwo ist das auch Kilometer an dem vorbei was wir da eigentlich mit den Sprachen tun. Ich will nicht ausschließen dass da auch jemand im großen Stil Fraktale und Co berechnet oder eben Binary Trees baut oder weiß der Geier, nur das Gros an Php Entwicklern wird wahrscheinlich 1000 foreach schreiben und 200 Db Abfragen eh sie einmal sowas anfassen, und da hört das dann irgendwie auf relevant zu sein wenn man nicht wirklich einen binary Tree mit drölftausend Knoten implementieren muss...
Bin mir gerade nicht sicher, ob das Kritik gegen meine Aussage ist?
Das ist ja im Grunde auch genau das, was ich meinte. Gerade mit NodeJS lassen sich ja die etliche Abläufe super parallelisieren und deswegen ist es PHP bei solchen Dingen eben auch überlegen in Hinsicht auf die Performance.
Wenn man eine Datei einliest oder 1-x DB abfragen hat, welche man nacheinander benötigt, dann ist es völlig irrelevant, ob ich PHP oder NodeJS nutze. Die beiden trennen dann vermutlich nur ein paar Millisekunden.
Weswegen ich für den TE NodeJs vorgeschlagen ist, weil er alles nötige schön im Speicher halten kann, während er in PHP die Session initialisieren, prüfen und ggf. DB-Abfragen machen muss und zwar bei jedem Request aufs neue.
Also, da ich zum Beispiel keine Webseiten entwickle, sondern hochgradig schützenswerte Extranet von ERP / CRM und DMS Systemen, also "echte Webanwendungen" (so mit 2FA Hardware-Token-Authentifikation, uvm.) und dabei die Sicherheit an aller erster Stelle steht, rotieren bei meinen Anwendungen während einer Session die SessionIDs fröhlich durch, damit man keinen Session Fixation Angriff drauf fahren kann. (Abgesehen davon, dass die Web Application Firewall 1. ohnehin die ganze Performance der Anwendung "frisst" und 2. Cookies via eines 2. Cookie mit HMAC signiert und diese Signatur prüft, damit niemand Cookies einfach so manipulieren kann usw.) Damit würde diese "Symlink-Methode" wegfallen bzw. das System enorm zuspammen und man müsste es mit dem Session-Controller verbinden, was irgendwie doof wäre.
Ein kleines Bildarchiv habe ich für ein Extranet aber auch schon umgesetzt, auf dem nur Teilnehmer eines Seminares und bestimmte Leute aus der Verwaltung Zugriff drauf haben dürfen. Dazu wird, wenn der Benutzer die Übersichtsseite aufruft, einfach die Berechtigungen für die Jeweilige "Galarie" in die Session gespeichert und das Skript, welches die Bilder ausliefert, prüft einfach die Berechtigung in der Session und nicht jedes mal von vorne aus der Datenbank. Denn auch da kann man so etwas wie ein DRY-Prinzip fahren. Warum sollte ich in kürzester Zeit immer wieder die gleichen Daten zur Berechtigungsprüfung aus der Datenbank laden? Das ist irgendwie Antipattern... Bei so etwas arbeitet man doch wohl über SoftwareToken (JWT oder ähnliches) oder Server Side Sessions, wobei letzteres im Vergleich zu JWT performanter für diese Aufgabe ist, da Krypto auch teuer für den Server ist.
Bin mir gerade nicht sicher, ob das Kritik gegen meine Aussage ist?
Das ist ja im Grunde auch genau das, was ich meinte. Gerade mit NodeJS lassen sich ja die etliche Abläufe super parallelisieren und deswegen ist es PHP bei solchen Dingen eben auch überlegen in Hinsicht auf die Performance.
Wenn man eine Datei einliest oder 1-x DB abfragen hat, welche man nacheinander benötigt, dann ist es völlig irrelevant, ob ich PHP oder NodeJS nutze. Die beiden trennen dann vermutlich nur ein paar Millisekunden.
Weswegen ich für den TE NodeJs vorgeschlagen ist, weil er alles nötige schön im Speicher halten kann, während er in PHP die Session initialisieren, prüfen und ggf. DB-Abfragen machen muss und zwar bei jedem Request aufs neue.
Ich wollte nur sagen dass Benches halt nicht unbedingt die Realität abbilden.
NodeJs: ja wenn der nunmal schon Php hat ist es doch wiedersinnig da jetzt noch NodeJs dranzuflanschen oder?
Der TE hat ja nun auch nicht soooo viele Infos gegeben (wenn hab ich sie verpasst) also was mich angeht reden wir hier von 20 Usern von einem Fußballverein die Partybilder nicht ins Netz stellen wollen.
Was jetzt die 'einfachste' Lösung dafür ist kommt sicher drauf an was man schon gemacht hat, sieht man ja: einer wirft redis drauf, einer schreit sofort NodeJs und einer machts übers Dateisystem. Der nächste baut vielleicht ne Batch mit Cronjob oder weiß der Geier, und alle setzen das wahrscheinlich performant in relativ wenig Code um. Und ehrlich gesagt ist es auch total wumpe solange es am Ende funktioniert und performant genug ist. Ohne die genauen Anforderungen ist due Diskussion halt müßig, nur wie gesagt: wenn jemand so eine Frage stellt wird der gefühlt eher mit keiner Lösung in Performanceprobleme laufen weil er wahrscheinlich nur 20 Nutzer hat die überhaupt die Gallerie aufrufen
Niemand(tm) außer Unternehmen in der Größenordnung Youtube, Facebook und Netflix brauchen solche Rocket-Science-Lösungen.
Deswegen würde ich mich auch lieber auf sicheren und sauberen Code statt auf abgefahrene Microservice-Node.js-Super-Skalierungs-Architektur für 2 Millisekunden weniger Ausführungszeit und lauter Bilder im RAM konzentrieren.
Aber Vorschläge im Sinne "Mach es so, weil es sicher ist und funktioniert", werden ja von Random Internet People rundergelutscht und mit Rocket-Science auf Facebook-Niveaou gekontert. Hauptsache es versteht am Ende niemand mehr.
