Bildupload nicht möglich - Seite 6

Seite 6 von 12 - Forum: Community Hub auf overclockers.at

URL: https://www.overclockers.at/community-hub/bildupload-nicht-moeglich_259561/page_6 - zur Vollversion wechseln!

mat schrieb am 14.03.2022 um 21:36

Zitat aus einem Post von COLOSSUS
Sorry, aber ich check es in dieser Formulierung immer noch nicht. Bedeutet

dass mit dem Ausrollen des von dir schon beinahe abgeschlossen vorbereiteten naechsten Upgrades oc.at nicht mehr in PHP implementiert ist?

Auch "Varnish und haproxy wird es in Zukunft nicht mehr geben." bedarf mMn einer Erklaerung, weil ich schaetze, dass irgendwas hier noch HTTP(S) sprechen soll am Ende des Tages?

Das neue Update ist natürlich weiterhin in derselben Codebase und daher in PHP.

Apache + FPM. War auch jetzt der unterste Layer. Auch wenn die TLS-Terminierung natürlich im haproxy stattgefunden hat.

COLOSSUS schrieb am 14.03.2022 um 21:45

Alles klar, danke - jetzt ist es unmissverstaendlich

In der naechsten/vorerst letzten Iteration ist dann nginx/caddy/envoy/younameit direkt vor php-fpm?

mat schrieb am 14.03.2022 um 21:58

Es bleibt dann nur mehr Apache + FPM über. In Kombination mit 2x Ivy Bridge-E mit insgesamt 12 Kernen und einer Menge DB-Optimierungen sollte die Performance nach wie vor sehr gut sein.

Viper780 schrieb am 14.03.2022 um 22:08

Verwendest du einen redis als DB Cache?

Apache gegen einen flotteren Server ersetzen ist keine Option?

smashIt schrieb am 14.03.2022 um 23:39

Zitat aus einem Post von mat
Ich habe böhmi und WM bereits geraten, einfach ein normales Invision laufen zu lassen. Der Port dorthin wäre natürlich schwierig, aber dann hat man ein laufend gepflegtes Forum.

invision ist leider kein vertrauenswürdiger vertragspartner

und seit sie damals alle mit perpetual lizenz verprellt haben scheint auch die support-szene tot zu sein.

COLOSSUS schrieb am 15.03.2022 um 08:10

Zitat aus einem Post von Viper780
Verwendest du einen redis als DB Cache?

Apache gegen einen flotteren Server ersetzen ist keine Option?

Effektives Caching ist nicht mit der Wahl einer Technologie (redis, memcached) allein erreicht. Es fragt sich auszerdem, ob bei dem Traffic, der oc.at erreicht, ueberhaupt ein Unterschied zwischen Daten-aus-mysql und (z. B.) Daten-aus-redis spuer- oder messbar waere. Weiters denke ich, dass mat das schon vor Jahren evaluiert haben duerfte; insb. memcache ist in der PHP-Szene ja keine unbekannte Geheimtechnologie.

Apache mit mpm_event ist ~ gleich "schnell" wie jeder andere moderne Webserver, der epoll/kqueue/usw. nutzt.

mat schrieb am 15.03.2022 um 08:41

Es wird APCu verwendet. Das reicht auch vollkommen aus.

HP schrieb am 15.03.2022 um 08:41

Danke für die Infos, mat!

Viper780 schrieb am 15.03.2022 um 09:08

Memcached gibt's ja schon lange und nicht unbedingt mit einem Keyvalue store zu vergleichen (aber die Überschneidung ist groß)

Apache hat halt den Nachteil der .htaccess datei. Er schaut bei jedem einzelnen Aufruf in jedem Ordner ob da eine liegt und versucht die zu parsen und interpretieren

Smut schrieb am 15.03.2022 um 09:14

Naja. Das ist eine Einstellung typischerweise bei Webhostern. Selbst machst das bei so einem Projekt anders bzw. deaktivierst den htaccess override.

COLOSSUS schrieb am 15.03.2022 um 09:18

Zitat aus einem Post von Viper780
Apache hat halt den Nachteil der .htaccess datei. Er schaut bei jedem einzelnen Aufruf in jedem Ordner ob da eine liegt und versucht die zu parsen und interpretieren

1. kann man das abstellen (wenn man sich auskennt), und 2. ist das (im Fall des Nichtvorhandenseins dieser Datei) genau ein Syscall bzw. Lookup in dentry-Cache, und bewegt sich deshalb im niedrigen Nanosekundenbereich auf moderner Hardware. Bei den meisten modernen Webapplikationen wird irgendwas im Dateisystem zudem nur noch fuer kleine Teile des URL-Namespaces abgefragt, da die meisten Requests z. B. zu einem php-fpm-Backend geroutet werden. Auch da ist dann kein .htaccess-Lookup im Spiel.

smashIt schrieb am 23.04.2022 um 22:41

falls ihr überlegt auf eine aktuelle version von vbulletin zu wechseln:

das steht da jetzt sicher schon 2 wochen.
und die hatten iirc nicht einmal mods intalliert...

einige der vbulletin leute haben sich vor ein paar jahren übrigens selbstständig gemacht:
xenForo
wäre vielleicht auch eine option.

xtrm schrieb am 23.04.2022 um 22:46

Die vBulletin Version von diesem Forum ist ja schon uralt, das wird kein Upgrade in dem Sinne erfahren behaupte ich .

davebastard schrieb am 23.04.2022 um 23:13

ja das wurde ja heftig umgeschrieben... würde mich auch wundern wenn da noch irgendwelche updates von vbulletin funktionieren

BiG_WEaSeL schrieb am 24.04.2022 um 08:49

Ich glaube das „based on vBulletin“ im Footer steht nur noch aus rechtlichen Gründen.