"Bestimmte Besucher bei Bandbreite präferieren?" und andere Ansätze.
-
Hallo,
die Schwierigkeit wird sein, dieses F5 abzufangen. Es gibt soweit ich weiß kein "OnReload"-Event und nur den Tastendruck abzufangen wird nicht ausreichen. Zumal ich mir als Nutzer ziemlich verarscht vorkommen würde, wenn ich die Seite nicht mehr akutalisieren dürfte wie mir das passt.
Ich denke die Downstreambegrenzung ist hier doch das bessere Mittel. Problem wird der Timeout sein. Da es sich momentan um VServer handelt (so wie der OP sagt), weiß ich nicht ob er/sie an die Config kommt, bzw. sie ohne Weiteres bearbeiten kann?!LG
-
Danke für die Meinungen bisher, etwas anderes als Downstreambegrenzung wird wohl nicht in Frage kommen, und User verärgern will ich auch nicht ^^
-
Vielleicht den nicht registrierten andere (kleinere auflösung oder Farbtiefe)
Bilder verpassen ? Könnte einen Menge Upstream einsparen.
-
pröf schrieb:
ich finde die "Rapidshare"-Variante mit der Warteschleife gar nicht verkehrt. Frage ist nur ob das irgendwas bringt. Man macht an der Stelle ja nichts anderes, außer den User etwas weiter nach hinten zu verschieben.
das wird nur gemacht, um die User zusätzlich zu einer Registration zu überreden. Zur Bandbreitenbegrenzung dient das nicht.
Afaik gibt es doch Webserver-Module, die die Bandbreite regeln können
Was braucht den am meisten Traffic?
-
Was braucht den am meisten Traffic?
Bilddateien.
Vielleicht den nicht registrierten andere (kleinere auflösung oder Farbtiefe)
Bilder verpassen ? Könnte einen Menge Upstream einsparen.Würde aber leider dem Sinn der Seite widersprechen, da kann man mit kleinen Bildern nichts anfangen.
Ich will halt einfach nicht irgendeine dämliche "nur für registrierte User"-Politik, weil sich die registrierten User ja aus unregistrierten rekrutieren und ich mich auch nicht wegen jedem Furz anmelden mag, um dann einen Account vergammeln zu lassen.
-
Recht einfach wäre wohl sowas in der Art zu machen, ob das in Deinem Fall auch sinnvoll ist, kann ich nicht beurteilen:
- Subdomain und VHost für registrierte User einrichten (premium.example.org oä.)
- Zugriff auf premium.example.org per Passwort schützen, wenn sich User nicht authen auf Non-Premium umleiten.
- Non-Premium und Premium mit unterschiedlichen Trafficshaping-Regeln versehen, dafür bw_mod oä. verwenden (habe da keinen guten Überblick mehr über brauchbare Apache-Module)
Gibt natürlich flexiblere und cleverere Ansätze, aber die brauchen im Gegensatz zu dem hier beschriebenen vmtl. länger als eine halbe Stunde.
-
wer nutzt denn für ein userportal apache oO
-
Ich! Was ist verkehrt daran?
-
overhead
-
PRIEST schrieb:
wer nutzt denn für ein userportal apache oO
Äh? Apache ist immer noch der mit Abstand am weitesten verbreitete HTTP-Server. Die Annahme, dass der verwendet wird, ist wohl nicht allzu abwegig.
Was denkst Du denn, was verwendet wird bzw. verwendet werden sollte?
-
PRIEST schrieb:
Lighty hat massive Schwierigkeiten mit SSL und Memleaks.
edit: Nur fürs Protokoll: Ich verwende durchaus auch andere httpds als Apache, aber so völlig ohne irgendwelche Anhaltspunkte und Hintergrundwissen zu behaupten, Apache sei ungeeignet, ist Käse.
-
kann ich nicht bestätigen
-
PRIEST schrieb:
kann ich nicht bestätigen
Nix für ungut, aber Du trägst nicht viel zu diesem Thread bei.
Gibts irgendwelche Probleme, die der OP beschrieben hat und die er mit Apache hat und mit Lighty nicht hätte? Nein? Wen interessiert es dann, welchen HTTP-Server er benutzt? Wieviel Erfahrung hast Du mit großen Webservern, dass Du sofort darauf schließt, dass die Tatsache, dass er Apache benutzt, in irgendeiner Weise interessant sein könnte?
-
nman, vielen Dank für deine Idee, ich denke, so werde ich das machen, vor allem mit wenig Aufwand
-
PRIEST schrieb:
overhead
Hmm,
hättest du jetzt gesagt IIS wäre overhead, dann hätte ich das ja verstanden, aber Apache
Ich habe mit dem Apache so gut wie gar keinen Aufwand. Installieren -> starten -> loslegen! Aufwand hab ich erst dann wenn ich "Features" benötige, die nicht zur Grundinstallation gehören. Aber auch dann verhält sich der Aufwand gerecht zum Nutzen.LG
-
Apache is nicht schlecht oder so, aber wenn man eine community o.ä. betreibt zählt für mich jeder funken performance und da fahre ich mit light einfach besser
-
PRIEST schrieb:
Apache is nicht schlecht oder so, aber wenn man eine community o.ä. betreibt zählt für mich jeder funken performance und da fahre ich mit light einfach besser
Na ja, wenn man nur 5 Besucher pro Tag hat, dann ist für deine Zwecke Apache auch übertrieben. :p
-
PRIEST schrieb:
Apache is nicht schlecht oder so, aber wenn man eine community o.ä. betreibt zählt für mich jeder funken performance und da fahre ich mit light einfach besser
Genau. Weil ja in der Praxis die Performanceunterschiede zwischen Apache und Lighty ausschlaggebend sind und nicht die Performance Deines Backends, die DB oder Deine Caching-Strategie?
Hast Du das gemessen?
Ist ja ok, Lighty zu verwenden. Aber dann zu behaupten dass es eine schlechte Idee sei, für größere Sachen Apache laufen zu lassen, ist einfach dämlich.
-
Also wenn ein Webserver fuer grosse Kommunikationsplattformen optimiert ist, dann doch wohl nginx. Davon abgesehen -- wie bereits angesprochen -- liegt die tatsaechliche Performance deines Servers nicht allein beim Webserver, sondern auch beim Datenbankserver und nicht zuletzt bei der Hardware (Prozessorleistung, Arbeitsspeicher, ...).
Ich persoenlich wuerde der Einfachheit halber das Download-Skript verwenden, weil man damit eigtl. recht zuverlaessig feststellen kann, ob jemand angemeldet ist oder nicht. Und man muss den anonymen Bereich nicht von dem der registrierten Benutzer trennen. Das entspricht ja der Vorstellung des Erstellers.
-
Nginx ist auch in einem projekt im einsatz. Versteht mich nicht falsch, apache ist nicht schlecht, aber hat im performancetest einfach immer den kürzeren gezogen.
Naja, will keinen religionskrieg anfangen :p
add: ja wurde gemessen ...
