OXPUS.de

Also ich wollte auf die Download Sektion in deinem Bereich "Eigene Mods" zugreifen und da hab ich diese Werte bekommen:

Loading 10.8057s (SQL:0.4996s = 5% | PHP:10.3061s = 95% | Queries 28) | 16 page(s) in the last 5 Min | Debug off | GZIP on

ich hab es extra 2mal gemacht und immer die selbigen Werte erhalten.

find ich ein bissel arg lang für DSL!

Es müssen auch über 45 Dateien gelesen werden Und das vom Server...

Hmmm - ist schon arg lang. Ich hab jetzt nur

Loading 7.1995s (SQL:0.2593s = 4% | PHP:6.9402s = 96% | Queries 27) | 6 page(s) in the last 5 Min

gehabt, was IMHO schon wehsentlich besser aussieht.
Ich hatte aber heute (bzw. gestern) allgemein den eindruck als würde oxpus.de ein wenig lahmen. Wer weis was da mit oder auf dem Server los war.

Gute Frage. Die Download-Zeiten sind bei mit meist noch etwas kürzer.
Aber ist vielleicht wirklich eine Frage der Uhrzeit...

Kann sein aber ich hatte auch das Gefühl das er ein bissel schwächelt. Woltle es ja nur gemeldet haben.

Ist ja okay.
Die Downloads der eigenen Mods werde ich aber auch nochmal reorganisieren. Bei der Masse ist eine Einteilung in weitere Kategorien wirklich bald dringend nötig.
Auch muss ich die Files für die anderen Kategorien mal in neue Verzeichnisse packen, damit die Prüfdauer verkürzt wird. Momentan sind ja alle "fremden" Mods in einem Verzeichnis. Und da dauert es eben ein wenig.

Warum muss er die eigentlich prüfen? Reicht es nicht den Link einfach zu laden? Haltich für schwachsinn wenn er immer eine Art Diagnoscheck durchführt.

Prüfen ist vielleicht das falsche Wort, aber es wird geprüft, ob die Files auch vorhanden sind. Ansonsten kommt es ja zu einer Fehlermeldung und der Download würde ja nicht klappen.
Dazu muss eben das Verzeichnis ausgelesen und bewertet werden, halt mit den gespeicherten Filenamen verglichen, und das kann dann eben dauern, wenn mehr im Verzeichnis steht.
Aber da fällt mir ein: Ich könnte mal nachsehen, ob der Mod das für jede Datei macht oder erst das Verzeichnis liest und dann vergleicht.
Letzteres dürfte schneller gehen.
Ich schaue da beim Reorg. mal gleich mit in das Script rein.

Ich könnte Wetten das er das bei jeder Datei macht

Mit!

Ja ja

sonst würd es ja nicht so lange dauern oder ^^

vielleicht fixte das ja ^^

Wenn ich es beschleunigen kann, bekommt Ihr den Code mitgeteilt. Hoffe nur, ich finde wirklich was.

Edit:
Erstes Prüfergebnis ergibt, daß nur die File-Grösse abgefragt wird und diese nicht in der Datenbank gespeichert wird. Das lässt sich nicht beschleunigen, da es ausschliesslich vom Server abhängt (oder man packt weniger Dateien in eine Kategorie).

Ich werde das umstellen, dann geht es wieder deutlich schneller.
Dann muss man aber als Admin gewährleisten, daß eine neue Fileversion auch im ACP bearbeitet wird, um die korrekte Dateigrösse wieder in der Datenbank zu speichern (was ich für mich ja eh tue). Das ist ja in der jetzigen, aber langsameren Version nicht nötig. Oder man lebt dann mit falschen File-Grössen

freue mich schon darauf

mal gespannt wie dein Ansatz ist und ob es viel schneller läuft

Nach meinen Berechnungen läuft es so schnell wie jede andere Seite auch, da ich nur beim Bearbeiten die File-Grösse abfragen lasse und ansonsten immer aus der Datenbank lese.
Dazu bastel ich noch eine Funktion, die nach dem Umstieg auf die neue Variante alle Files auf einmal prüft und auch später immer wieder verwendet werden kann.
Dabei werden natürlich nur die File-Grössen aktualisiert, die abweichen. Zeitersparnis halt auch hier.

EDIT:
Hier gehts zu den entsprechenden Anpassungen des Download-Mods:
http://www.oxpus.de/viewtopic.php?p=11444#11444

ah gut, verstehe ^^ hoffentlich vergewaltigigts du nicht wieder ne SQl Datenbank dafür ^^

davon hab ich nämlich schon soviele (Einträge)

*grins*

Nö, ich füge nur ein Feld hinzu in dem lediglich beim Erfassen, bzw. Editieren von Dateien die Filegrösse eingetragen wird. Mehr nicht.
Ergebnis: Deutlich höhere Performance!

hast schon geändert oder ^^

Ich kanns net leider wenn die SQl total versmoggt aber ein Eintrag ist ja ok ^^.... *gute Arbeit*

Danke danke.