Reloadsperre

Problem wäre dann nur noch die Cookie-Größe. 4 KiB sollte jeder Browser unterstützen. Hat jemand Erfahrungen damit, wie Browser mit Überlänge umgehen? Nehmen die dann gar nicht an oder schnibbeln die ab?

Im Falle von Schnibbeln und serialize() wäre der Keks dann komplett im Eimer. Serialisieren eines Arrays mit serialize() erzeugt eh massig Overhead. Ich würde auf alle Fälle n delimiter-getrenten String verwenden, z.B. "1;2;3" (am besten kein Komma, um nicht in Versuchung zu kommen, den Keks ungefiltert in die DB-Query zu setzen ;)).

Wird aber dennoch knapp: 500 IDs im Keks, 500*4-1 = 1,95 KiB.
Lass die IDs mal größer werden und n paar Seiten dazukommen, dann wirds eng.
 
Ihr denkt viel zu kompliziert.
Meine Idee war einfach die IDs Kommasepariert im Cookie abzulegen.
Was schon drin ist, wird nicht vergütet oder was auch immer sonst damit nicht passieren soll.

Die 4Kb Problematik ist allerdings real. Das könnte man z.B. mit einer Serverseitigen Prüfung abfangen. Ist das Cookie größer wird der Anfang entfernt, das neue hinten dran gehangen. Ein einfaches Stack-Verfahren.

Ob es Performance-Vorteile bringt muss man selbst wissen. Zu Beginn wurde von vielen Datensätzen gesprochen, oft sind solche trivialen Lösungen eine zusätzliche Option Überlastungen zu reduzieren oder zumindest zu verteilen. Viel mehr aber auch nicht.

Die Cookie-Idee, war aber eben nur eine Idee. Ohne das gesamte Problem zu kennen, kann man keine Lösungen ausarbeiten. Drum ist die DB-Performance Beschreibung viel relevanter und sollte sowieso als erstes umgesetzt werden. ;)
 
Eine Idee wäre es die Zahlen in Gruppen zusammenzufassen und diese dann per Komata getrennt zu speichern. Das würde den Platzbedarf sehr verringern.
Wird halt dementsprechend mehr Aufwand zu überprüfen ob die Zahl vorhanden ist oder nicht.


Hier ein Beispiel wie ich das meine.

Code: 
Eingabe: 1 2 3 6 8 12 13 14 15 100 101 102 103 104
Ergebnis: 1-3,6,8,12-15,100-104

Im schlechtesten Fall müsste man die Hälfte der Zahlen speichern.

Ich weis leider nicht ob es für dieses Verfahren ein Namen gibt, wenn es jemand weis nur raus damit. :p
 
Darklord schrieb:
Ich weis leider nicht ob es für dieses Verfahren ein Namen gibt, wenn es jemand weis nur raus damit. :p
Zum Vergrößern anklicken....
Jupp, nennt sich Kompression ;)

Die Frage is nur, ob sich der Aufwand lohnt:

  • n*log(n) für Sortierung der IDs
  • zusätzlich n, um die Gruppen zu erfassen
Darklord schrieb:
Im schlechtesten Fall müsste man die Hälfte der Zahlen speichern.
Zum Vergrößern anklicken....
Nö. Worst-Case musst du alle Zahlen speichern:
Code: 
[LEFT]Eingabe: 1 3 5 7 9 11 13
Ergebnis: 1,3,5,7,9,11,13[/LEFT]
Mal weiter gedacht: Statt die Info, welche IDs in Reloadsperre sind, komprimiert im Keks zu speichern, könnte man einen Schlüssel verwenden, den als einziges Datum im Keks ablegen und die Zuordnung Schlüssel zu den IDs in der DB machen.

Und wer jetzt sagt, dass sich diese Idee gut anhört, der stellt fest: Dann sind wir beim ursprünglichen Problem - nämlich: speichern wir halt gleich alles in der DB ;)
 
Warum so kompliziert? Dafür wurden doch Sessions erfunden. Allerdings dürfte sogar der Ausschluss einiger (50?) IDs ineffizienter werden, als direkt über JOINs gegen eine Reload-Tabelle zu prüfen.
 
Irgendwie geht mir der Sinn des Cookies dann überhaupt nicht rein. Wenn letztlich eh nicht die DB überstimmt werden soll, warum wird der ganze Käse dann überhaupt auf Cookie-Ebene verlagert?

Die 5 Mio Einträge müssen doch irgendwo gespeichert sein
  1. Server - In der Datenbank
  2. Server - Dateiebene (Sessions)
  3. User - Cookie

Die ursprüngliche Frage war, wie man Nr. 1 vermeiden könnte. Aber warum eigentlich? Der Speicherplatzverbrauch ist in 1 und 2 identisch, reine 3 wegen Manipulierbarkeit ausgeschlossen. Irgendwo auf dem Server müssen die Einträge also auf jeden Fall liegen. Und die Zugriffszeit ist bei 1 vermutlich besser als 2 und sicher besser als 3.

Wenn es nun eine Liste in 1 und 3 gibt, wo soll dann der Vorteil gegenüber 1 sein?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben