Freundschafts-Pfade

[Surviver]

Coole Sache - habe mir darüber auch mal gedanken gemacht, habe auch noch ein paar Ideen wie man das vllt relativ effizient lösen kann.

Wie sieht es denn hier mit der Performance aus?

[Andreas]

Relativ gut, sonst hätte ich es nicht veröffentlicht
Seit dem Beitrag habe ich aber noch einige Dinge geändert, sodass es mittlerweile meist bei deutlich < 0,1 Sekunde liegt.

Wobei ich vorhabe das in einer der nächsten Versionen noch zu beschleunigen (Memory-Tabelle, berechnete Pfade speichern).

Edit: Da steht nix im Header, muss du dich getäuscht haben

Im Debug-Mode wird (sofern PHP 5) angezeigt wie lange die Berechnung gedauert hat, über Feedback würde ich mich sehr freuen

[Surviver]

Aah, coole Sache

Sollen die Pfade in einer Memory Table gspeichert werden? Oder wofür sollen die verwendet werden?

Gruß Julian

//EDIT: Sieht ja vielversprechend aus Das mit den Memory Tables + Stored Procedures würde mich mal interessieren

[Cosmo]

Absolut, coole Sache.
Nur ich habe als Betrachter das Problem, das mein Avatar nicht angezeigt wird, aber bei meinen "Freunden" schon.

Es müsste dieser Dateiname gelesen werden:
./customavatars/avatar2_4.gif
gesucht wird aber:
./customavatars/avatar22_.gif

Edit:
A <-> B
A hat dieselbe Userid wie B, also A nimmt die Userid von B an.

[Andreas]

Zitat von Surviver

Aah, coole Sache

Sollen die Pfade in einer Memory Table gspeichert werden? Oder wofür sollen die verwendet werden?

Nein, das wäre blöd wenn der Server mal neu gestartet wird

Das was jetzt in userlist drinsteht soll in eine MEMORY-Tabelle, da diese doch um einiges schneller ist als eine normale (MyISAM, InnoDB) und userlist obendrein unnötige Daten enthält (es werden ja nur die Datensätze mit type=buddy & friend=yes benötigt)

Stored Pocedure wollte ich ursptünglich machen (da das recht elegant geht), aber a) hat MySQL ein Problem mit temporären Tabellen der ein Show-Stopper ist (es ist nicht möglich diese mehrfach zu referenzieren) und b) haben halt noch zu viele User kein MySQL 5.

[Surviver]

Nein, das wäre blöd wenn der Server mal neu gestartet wird

Deshalb fragte ich ja

Vom Prinzip her ist dieser Hack ja gar nicht soo komplex, mich intressieren halt, wie man das Seitens MySQL noch optimieren kann (Auch für die Zukunft )
Denn für MySQL ist das ja schon eine komplexe Operation.

@Stored Procedures: Bekommt man dadurch denn einen Geschwindigkeitsvorteil? Und wie sieht es aus, wenn man das Teil in einer Social Community mit 1.000.000 mitgliedern einsetzen würde, wo Buddylist usw auch aktiv genutzt werden? Da müsste man wahrscheinlich einen eigenen Server für die Berechnung abstellen, oder ist das nicht so schlimm?

(Sorry für die Vielen Fragen, finde das aber sehr interessant )

[Andreas]

@Cosmo
Korrekt, da war noch ein kleiner Fehler bzgl. der UserIDs drin (die müssen getauscht werden) - sollte jetzt stimmen.

@Surviver
Mit Stored Procedure und funktionierender Temporary Tables sollte es effizienter sein als der jetzige Ansatz (da nicht ständige soviele IDs durch die Gegend geschoben werden müssen).
Wie gut es mit größeren Communities skalieirt kann ich mangels Testwerten nicht sagen, aber theoretisch sollte es kein allzugroßes Problem sein.

[Cornie]

Gute Idee der Hack,

aber ich bekomme eine fehlermeldung und es zerreisst mir den Style indem er im Profil die rechte Seite, Kurzinfo usw. nach unten drückt.

Warnung: uniqid() expects at least 1 parameter, 0 given in [path]/includes/class_profileblock.php(550) : eval()'d code (Zeile 7)

[Andreas]

Der parameter ist bei aktuellen PHP-Versionen optional, ergo:
Schmeiß dein PHP 4 dahin wo es hingehört: In die Mülltonne

Anyway, mit Version 1.0.2 tritt diese Fehlermeldung nicht mehr auf.