Ab sofort gibt es bei Tempus-vivit! eine Benachrichtigung an die hinterlegte Email-Adresse wenn man interne Post erhalten hat.
Speziell bei Rückfragen zu Marktanzeigen oder bei ausgiebigen Diskussionen über die Nachrichtenfunktion wird man so schnell über neue Nachrichten informiert.
Die Diskussion wie ich sowas speichern würde ist doch müssig. Ihr habt die Daten irgendwie gespeichert, ob nun über MySQL, in ner Textdatei, sqllite oder whatever.
Bei der Frage Ajax sinnvoll oder nicht dreht es sich nur um die Frage, wann und wie diese Daten abgefragt werden.
Vor einer Weile wurde ja die Freunde-Funktion vereinfacht, so dass plötzlich _alle_ Personen, auf _deren_ Freundesliste ich zu sehen war, endlich auch auf _meiner_ Liste zu sehen waren.
Letztens habe ich jemandem die Freundschaft angetragen und sie wurde (dankeschön) auch angenommen. Jetzt ist diese Person auf _meiner_ Freundesliste, ich bin aber nicht auf _ihrer_ Liste ….. und wir haben keinen Weg gefunden, wie ich auf _ihre_ Liste komme …..
Wenn überhaupt, würden sich bei den Auto-Reinigungs-Funktionen Zeiträume von 3-6 Monaten anbieten. Das sind die Zeiträume, in denen viele User vorbeikommen. Damit könntest Du dann vielleicht die Datenmenge halbieren, mehr ist aber nicht drin.
Die Threadansicht kannste nicht cachen, da du für jeden Benutzer eine unterschiedliche Variante cachen müsstest. So hättest Du 41.000 Varianten von der Rubrik TV! intern im cache rumfliegen, denn jeder hat unterschiedlich gefärbte Fähnchen.
Wird nun etwas neues geschrieben, musst Du bis zu 41.000 gecachte Ansichten der Threadliste plus 41.000 gecachte Ansichten des Rubrikenbaums aus dem Cache entfernen. Danach wird dieser Cache langsam wieder aufgebaut wenn die entsprechenden User die Liste abrufen. Dies tun sie gewöhnlich weniger als 5x für jede Rubrik, sodass der Cachingaufwand gegenüber dem Nutzen überwiegen würde, Du hättest ein Verhältnis von 1:5. Aktuell haben wir ein Verhältnis von 1:500 oder besser, da alle User die gleiche gecachte Ansicht der Threadliste nutzen können.
Im Worst Case. Man kann aber auch nen Zeitpunkt definieren, ab dem Beiträge automatisch als gelesen markiert werden. z.B. 24 Stunden. Dann braucht man nur noch die Threads speichern, die innerhalb der letzten 24 Stunden aktualisierten und angesehen wurden.
Die Tabelle wird natürlich regelmäßig gereinigt, so daß angesehene Threads, die Älter als 24 Stunden sind automatisch rausfliegen, da alleine ihr Alter als “gelesen”- Kriterium ausreicht.
Damit hätte man deutlich weniger Daten (abhängig natürlich, wie viele Threads innerhalb der letzten 24 Stunden aktualisiert und gelesen wurden).
Aber es erschließt sich mir nicht ganz, warum man die Threadansicht cachen kann, die Threadliste nicht, denn je nach Postingfrequenz ändert sich beides für den User gleich schnell.
Das von Dir vorgeschlagene Modell hat im Worst-Case 144.000 x 41.000 Datensätze mit jeweils 12 Bytes, was eine Tabellengröße von 65GB bedeuten würde, ohne primary keys usw. ;-)
Wenn man nur die Threads und nicht Bibliothek, Calendarium, Markt usw. betrachtet, hat man 4.000 Threads. Das führt immer noch zu einer Tabellengröße von 4.000 x 41.000 mit jeweils 12 Bytes, also 1,9GB.
Man muss sich also überlegen, wie man das effizienter gestaltet, den in 1,9GB zu suchen für JEDEN Aufruf der Threadliste würde das System ziemlich ausbremsen. Und cachen kann man solche Daten auch nicht, da sie sich zu schnell verändern für jeden Benutzer. Man muss sich also was effizienteres einfallen lassen. Kann sich eine Speicherung, wo man Informationen zusammenfasst, nicht mit Joins vertragen.
Jetzt zu Deiner Frage mit dem Ajax: Wenn wir die Flaggen nachholen und den eigentlichen Content separat ausliefern, können wir den Content zumindest zwischenspeichern im Cache, was uns einiges an Zeitersparnis bringt.
Ich würde es so machen, wie z.b. das vbulletin. Datenbanktabelle mit userid, threadid und nem timestamp.
Und mit Subqueries und/ oder gut designten JOINS und der Verwendung von NOT IN dürfte das kein Problem sein
Aber Gegenfrage: Welchen Unterschied macht Ajax oder nicht, auf die Art und Weise wie ihr die gelesenen Threads speichert?
Es geht ja nur darum, wann und wie ihr diese Information auslest und auswertet. Vorhanden sein müssen sie ja.
Ob ihr erst die Seite generiert, dann per Javascript- Request nen php- Script anschubst, was euch die gewünschten Daten liefert, oder ob ihr diese Daten gleich beim generieren der Seite euch holt und dort einfügt, macht auf die Art wie ihr es speichert doch keinen Unterschied.
Du hast Recht, ich hab Deine “Kein Ajax” Aussage ein wenig durch den Kakao gezogen.
Ich hab aber auch grade mal mein Profil auf Studivz aufgemacht und mal geschaut, was denn so an Anfragen läuft. Dies wären neben den Bildern, Stylesheets und Werbebannern noch folgende: 3 Ajax Anfragen für den Chat, 4 für dynamisch eingebundene Fenster (“Kennst Du schon”, “Neue Freunde”, “Deine Gruppeninfos”, “Letzte Besucher”) sowie eine Anfrage für JEDEN Beitrag im Buschfunk. Insgesamt 13 Stück.
Bei Google Maps wird beispielsweise JEDER Kartenschipsel per Ajax-Request geholt.
Unser Grund, Ajax zu benutzen ist folgender: Es ist so einfacher zu programmieren und reduziert die Serverlast immens. Denn alle User bekommen die gleiche Threadliste angezeigt und nur die Fähnchen unterscheiden sich und müssen für jeden separat geholt werden.
Kleine Denksportaufgabe: Wir haben aktuell knapp 144000 Einträge bei Tempus-vivit, bei denen es sich lohnen könnte, den gelesen-Status zu speichern und 41.000 registrierte Benutzer. Wie würdest Du mit Deinen 10 Jahren Webentwicklungserfahrung (ACHTUNG! DAS IST NICHT BÖSE GEMEINT SONDERN EINE EHRLICH GEMEINTE FRAGE) diese Informationen abspeichern, um innerhalb einer SQL-Abfrage von allen Elementen (z.B. Threads in der Liste) diese Informationen holen zu können und die Informationen auch mit recht geringem Aufwand propagieren zu können? (= Wenn alle Threads in einer Rubrik für diesen User gelesen sind, dann ist die Rubrik auch gelesen, wenn wieder jemand etwas schreibt, ist sie wieder ungelesen)
Würdest Du speichern, welche Sachen bei einem User bereits gelesen wurden oder würdest Du speichern, was noch nicht gelesen wurde…? Und wenn ja, wie?
@Carsten: Lies meine Sätze bitte zu ende und zerhacke sie nicht.
Keine große Software verwendet AJAX für diese Tasks.
Um das auf mein Flugzeugbeispiel umzumünzen: Ich habe nicht geschrieben “keiner benutzt Flugzeuge” sondern “keiner benutzt Flugzeuge um damit 100m weiter Brötchen zu holen”.
Schau dir phpBB, vBulletin, wBB, SMF, viscacha, ipb etc. pp alle benutzen (zum teil exzessiv) Ajax. Aber keins verwendet es dazu, die Markierung der Threads zu generieren oder die Usernamen auszugeben..
Definiere doch selber, wodurch sich der Mehrwert der Ajaxtechnologie beim generieren der Fähnchen und ersetzen der Namen beim Benutzer auszeichnet?
Also ich verzeichne nur, daß es selbst auf meinem Desktoprechner ne merkliche Zeit dauert, bis die ganzen Requests abgearbeitet werden und auf meinem Netbook ist TV fast gar nicht verwendbar, weil die Seite meinen kleinen reglmäßig an die Grenzen seiner Leistungsfähigkeit bringt und regelmäßig einen kompletten Systemfreeze provoziert. Und das unter Linux…
Das ist jetzt nicht so, daß ich einfach nur substanzlos Kritik üben will, ich denke dadurch, daß ich schon seid knapp 10 Jahren in der Webprogrammierung unterwegs bin und an Webseiten mit gearbeitet habe, die mehrere hunderttausende Besucher im Monat (eindeutige Besucher, nicht Seitenhits) haben/ hatten, daß ich schon, daß ich die ein oder andere Ahnung von dem habe, was ich hier sage.
Ich hab ja nix gegen Ajax und bin alles andere als einer dieser “ihh, dieses doofe Web 2.0 Gedöns” ich bin nur der Meinung, daß das Ajax für diese beiden spezifischen Aufgaben nicht die beste Technik ist.
Das ist halt meine Meinung, und wenn ihr andere Meinungen zu eurer Technik nicht haben möchtet, dann kann ich das auch akzeptieren.
Software/Webseiten wie Google Maps, Digg, Gelbe Seiten, Gmail, Flickr, *-VZ, Last.fm würd ich nicht unbedingt als klein bezeichnen. Und alle machen sie intensiver Gebrauch von Ajax als wir.
@Carsten: Schon recht, daß die Zukunft Ajax gehört, aber doch nur da, wo sie angebracht ist.
Mit jeder Ajaxanfrage erhöhe ich unnötigerweise die Fehlerquellen (und auch mögliche Sicherheitslücken), erhöhe den Ressourcenverbrauch auf Client und Serverseite.
Ajax mag vielleicht “neu sein”, aber wo es ein Problem nicht besser löst, sondern eher schlechter, dann sollte man die Technologie anwenden, welche die effizienteste ist.
Um es mal so zu sagen: Flugzeuge sind zwar das modernste Fortbewegungsmittel, um 100m weiter Brötchen zu holen, ist ein A380 eher unpraktisch ;)
Und da kann man sich mal überlegen, warum _keine_ größere Websoftware, egal ob kommerziell oder open source ähnliche Tasks mit Ajax löst.
Ajax wird in der Regel da eingesetzt, wo ich einen Mehrwert in der Interaktion zwischen Webseite und Nutzer und für den Nutzer ist es egal, ob die Fähnlein allein Serverseitig oder mit Ajaxunterstützung gemacht werden. Solange es funktioniert, eine Verbesserung der Nutzbarkeit findet nicht statt.
Wenn das jetzt ein Glaubensstreit über Webapplikationen wird, muß ich das Phrasenschwein aufstellen, und für jede Pauschalaussage und jedes Buzzword wird eingezahlt.
Einloggen
Anmelden
Mobile Ansicht
Bitte einloggen, um Carsten eine Nachricht zu schreiben.
: 
antworten
Neue Einträge oberhalb dieser Markierung