"Bestimmte Besucher bei Bandbreite präferieren?" und andere Ansätze.
-
Servus,
Ich bin momentan Betreiber eines Webportals, dessen Server dem Ansturm mittlerweile nicht mehr ganz gerecht wird (d.h. Bandbreite, von der Leistung her geht es, ist kein dedicated Server, sondern virtual), viele Bilder.
Nun werde ich mir wohl einen Rootserver holen, das kann aber etwas dauern, deshalb suche ich für die Übergangszeit Lösungen. Auf dem Portal gibt es einige (ungefähr 30%) registrierte User und Donors, welchen ich eigentlich Zugang ohne Performanceverluste ermöglichen würde, die Gäste sind mir dann erstmal relativ egal bzw können gerne gedrosselten Zugang haben. Gibt es Möglichkeiten, wie ich das realisieren könnte?Meine derzeitigen Denkansätze:
- Ab einer bestimmten Anzahl von aktiven Usern die nicht registrierten User einfach mal kurz auf eine "Wartepage" umleiten, die können es dann später wieder versuchen (Problem: es könnte zu einer F5-Orgie kommen, weil die Leute reinwollen -> eventuell Pflichtwartezeit für Refresh einbauen?)
- Unregistrierten Usern eine Version der Seite ohne Bilder zur verfügung stellen (wäre halt etwas mehr Aufwand)
- andere Möglichkeiten?
Am liebsten wäre es mir, wenn alle normalen Zugriff hätten, nur eben die registrierten User bevorzugt werden würden, d.h. die Unregs müssten dann halt mit langsamerem Seitenaufbau rechnen. Ist so etwas möglich? Auf dem Server läuft Apache.
Es ist halt leider einfach so, dass ein kleines Projekt mittlerweile viele Leute anlockt und ich mir sowieso alles nochmal neu machen muss, um dem Ansturm gerecht zu werden, aber eine temporäre Lösung wäre schon und ich würde mich über Meinungen, was (auch für die Unregs) am attraktivsten ist, freuen.
-
Hallo,
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.
Zur Downstreambegrenzung ist das vielleicht ganz hilfreich.
LG
-
Bei dieser Speedbegrenzung durch ein PHP Script stelle ich mir jedoch die Frage, ob das dann nicht die CPU stark beansprucht. Schließlich würde die Ausführungszeit der Scripts stark steigen.
Außerdem scheint es dem OP ja auch um Bilder zu gehen. Diese müssten dann auch irgendwie den Umweg über dieses Script nehmen.
-
Bei der Wartepage könnte man auch ein Captcha einbauen. Dadurch kann dann nicht mehr F5 gedrückt gehalten werde: Man müsste zunächst ein neues Captcha eingeben.
Aber na ja...
-
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