PHP Bilder nur für internen Bereich

[Bagbag]

Schön dass du die ultimative Lösung finden willst aber die gibt es hier mit den Infos nicht.

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:

die Bilder eines Users bei Anmeldung per Symlink in einen Ordner mit der SessionId zu spiegeln und aus dem auszuliefern, dann brauchst du nur eine Liste aktiver Sessions zu halten und wenn eine ausgelaufen ist deren Symlink zu löschen

Am Besten noch ein Request je Bild, da kannste zugucken wie die Performance in den Keller geht.

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.

 

[mambokurt]

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:



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.

Da hast du jetzt ein kleines Problem weil ich so ein bisschen in der kruden Realität lebe und in der sind 50 Anfragen an die Db halt 50* Latenz. Schön dass du redis anführst nur weder wissen du noch ich ob das Not tut noch wissen du oder ich ob das überhaupt gerechtfertigt ist. (Mal davon ab könnte man das genausogut in eine Phpsession schieben, und das wäre fixer)

 

[Bagbag]

Also ich würde die 50 abfragen parallel und nicht nacheinander machen. Cool was in der Realität so alles geht. So ist es nur ein klein wenig mehr als 1x die Latenz. Zumindest können alle Datenbanken mit denen ich bisher gearbeitet habe entweder mehr als eine Abfrage zur selben Zeit oder sind so absurd schnell (wie bspw redis), dass das keine Rolle spielt (zumal das Senden da trotzdem parallel geschehen kann, somit auch da nur knapp über 1x Latenz).

Ich rede nicht von Redis als Session, sondern eher von Redis als persistente Datenbank.

Und doch, ich weiß ob das Not tut: nein, tut es nicht. Die gängigen SQL Datenbanken machen die 50 Abfragen mit links mehr als schnell genug (keine absurde Datenstruktur vorausgesetzt). Woher ich das weiß? Weil ich genau das schon entwickelt habe. Sogar komplexer als einfach nur öffentlich/privat, sondern mit mehreren Nutzergruppen und Rollen. Rein aus einer SQL Datenbank, jedes Bild bei jedem Aufruf auf Berechtigung überprüft, das parallel, mehr als schnell genug.

 

[ayngush]

Wenn in einem HTML-Output 50 Bilder referenziert sind und 50 Bildressourcen unmittelbar angefordert werden, dazu 50 Verbindungen zum Server aufgebaut werden (http/1.1) und das Skript dahinter in der Folge 50 Verbindungen zur Datenbank initialisiert und 50 Abfragen stellt (jeweils schon kumuliert), dann sind nicht die 50 Datenbankabfragen das Problem (die in der Tat sehr schnell und bei 50 absolut kein Problem sind), sondern die 50 Verbindungsversuche - sowohl auf das Skript vom Webserver her als auch vom Skript zu der Datenbank hin. Man würde, wenn das Skript keinen Datenbankaufruf benötigt, die Antwortzeiten in dem Fall loker halbieren.

 

[Bagbag]

Und deshalb machen browser das nicht, sondern afaik maximal etwa 5-7 parallel, je Domain. Mit keep-alive bleibt es auch mit http 1.1 bei der selben Verbindung. Ein Connection Pool zur Datenbank sollte mit 7 parallelen Abfragen ebenfalls nicht überfordert sein.

Zumal lazy loading bald ja noch viel einfacher als bisher wird, mit dem neuen Feature des Chromium (bei dem Firefox sicher bald nach zieht).

 

[ayngush]

"Die Browser" machen das, was im Protokoll vereinbart ist.

Lazy loading ist eben genau so eine Technik dafür, den Seitenaufbau durch die ganzen Connection-Anfragen und das Laden der Ressourcen nicht allzusehr zu beeinträchtigen.

Mit http/2 fallen ja schon mal die Verbindungsinitialisierungen im TLS Bereich größtenteils weg.

Unabhängig davon: Wenn ein Skript immer wieder eine Verbindung zur Datenbank aufbauen muss, dauert das eben. Es gibt da viele Optimierungstechniken aber wenn man sich zum Bilderladen die Datenbankverbindung sparen kann, dann merkt man das unmittelbar in der Gesamtperformance.

 

[Bagbag]

Die Anzahl der Verbindungen ist aber in HTTP/1.1 nicht fest definiert, sondern es wird nur empfohlen es überhaupt zu limitieren (siehe https://tools.ietf.org/html/rfc7230#section-6.4). Das sind also letzten Endes Entscheidungen der Browserentwickler und ist auch nicht bei allen Browsern identisch. Häufig lässt sich das in den erweiterten Optionen auch ändern. Bei HTTP/2 stellt sich die Frage ja erst gar nicht, da es hier mittels Multiplexing gelöst ist.

Lazy-Loading ist dazu da den Seitenaufbau schneller zu machen und (mobile) Daten zu sparen, in dem nur das geladen wird was der Nutzer gerade sieht, korrekt. Aber das hat (meistens) weniger mit dem Server und der Datenbank zu tun, sondern vielmehr mir der begrenzten Bandbreiten und dem Datenvolumen des Nutzers.

immer wieder eine Verbindung zur Datenbank aufbauen muss, dauert das eben.

Und genau das ist bei einem Datenbank-Client der was taugt nicht der Fall, da hier einerseits Connection-Pools genutzt werden wodurch eine bereits aufgebaute Verbindung augenblicklich zur Verfügung steht und andererseits vorhandene Verbindungen wiederverwendet werden.

 

[owned139]

Ordner mit htaccess-Schutz + Sessions und Bildausgabe via PHP.
Wenn dir das zu unperformant ist (warum auch immer?!), dann kannste NodeJS nehmen, die eingeloggten User im Speicher halten und dort abfragen.

 

[Sparta8]

Aber Imho liest der TE hier eh nicht mehr mit, von daher ist es eh egal.

Doch doch, ich les noch mit. Viele unterschiedliche Meinungen und Ansätze. Guter Meinungsaustausch.

 

[Piktogramm]

@owned139
Naja Node zieht PHP seit den 7.x Releases nicht mehr so einfach die Butter vom Brot. Zudem PHP Sessiones sowieso einige Zeit als File vorhält (in der Regel liegt dies Session_ID damit im Ram). Wer mag kann versuchen mittels PHP apcu ja auch nicht versuchen etwas Leistung herauszuholen.

 

[owned139]

@Piktogramm
NodeJS ist je nach Anwendungsfall um einiges schneller als PHP. Bei Node lässt sich alles schön im Speicher halten, während bei PHP jeder Request eine neue "Instanz" startet und alles wieder von vorn beginnt.

 

[ayngush]

Bei PHP beginnt (auch) nicht mit jedem Request "alles von vorn".
Und: https://thinkmobiles.com/blog/php-vs-nodejs/ wenn dein "Anwendungsfall" ausschließlich das Addieren von Zahlen ist, dann ist Node.js schneller, ansonsten wird es von PHP ordentlich an die Wand gefahren. Insbesondere, was die Skalierung auf 1000 Requests in 1000 Threads angeht. (32 ms Response zu 200 ms)

To put this numbers into a somewhat more acceptable form, PHP is capable to process 31,250 queries per second, Node.js, on the other hand, can deal with 5,000 queries per second.

Und die haben da PHP 7.1.x getestet. 7.2 und 7.3 haben da nochmal deutlich zugelegt.

 

[Piktogramm]

Falls du mit "Instanz" Prozesse meinst. Das kann Apache und PHP in Verbindung mit FastGCI mittlerweile deutlich besser als von dir beschrieben. Wobei die Grundkonfig bei den meisten Linux Distries sinnvoll über die Installation der Paketmanager erfolgt.

 

[Sparta8]

NodeJS kann non-blocking I/O. Kommt aber drauf an wie man die Datei einliest. Darauf wird im Benchmark nicht eingegangen.

 

[ayngush]

...kann PHP (zum Teil) auch...

 

[owned139]

Nein.
Die MySQL Verbindung ist synchron und nicht asynchron. PHP kann generell nicht Asynchron, außer in CLI.
Btw. ich habe mehr als 6 Jahre Berufserfahrung mit PHP und großen Frameworks. Ihr braucht mir nicht erzählen was es kann.

 

[ayngush]

Doch...
https://entwickler.de/online/asynchronous-io-in-php-oder-doch-lieber-threads-137913.html
Aber das wird mir hier auch langsam zu albern
https://reactphp.org/


Edit: mal was zum Benchmarken:

<?php
session_start();
$auth = $_SESSION['authenticated'];
session_write_close();
if ($auth === true) {
    header("Content-Type: image/png");
    readfile(__DIR__."/../images/bild.png");
    flush();
}

 

[owned139]

Mensch...
PHP war dafür nie konzipiert. Dass man sich das irgendwie zurecht biegen kann ist richtig, aber das ist einfach kacke! Und nein MySQL ist in PHP synchron. Wer asynchron und non blocking I/O haben will ist bei PHP falsch. Mit Java kann ich auch 3D Anwendungen bauen, aber das ist einfach kacke. Wer PHP für async und nonblocking i/o nutzt, hat PHP nicht verstanden.

 

[Bagbag]

Bei PHP beginnt (auch) nicht mit jedem Request "alles von vorn".
Und: https://thinkmobiles.com/blog/php-vs-nodejs/ wenn dein "Anwendungsfall" ausschließlich das Addieren von Zahlen ist, dann ist Node.js schneller, ansonsten wird es von PHP ordentlich an die Wand gefahren. Insbesondere, was die Skalierung auf 1000 Requests in 1000 Threads angeht. (32 ms Response zu 200 ms)


Und die haben da PHP 7.1.x getestet. 7.2 und 7.3 haben da nochmal deutlich zugelegt.

Ohne Quellcode zum nachtesten ist das nicht vertrauenswürdig. Die haben da vielleicht kacke programmiert, weil sie Node.js nicht können?
Außerdem nutzen die da Node.js 6, das ist schon uralt und bei der V8 Engine hat sich seit dem extrem viel getan.

 

[ayngush]

Die nutzten da auch PHP 7.1, das ist auch "uralt".
Kann das sein, dass das damals(tm) wohl aktuell war...
Und wenn du den Tests als Wegweiser nicht traust, steht es dir frei auf die Bühne zu kommen und es besser zu machen.