Page MenuHomePhabricator

Thumb generation very slow
Closed, ResolvedPublic

Description

MV is slower then thumb.php...

It takes too long to load this should be improved.


Version: master
Severity: normal

Details

Reference
bz67848

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:37 AM
bzimport set Reference to bz67848.
bzimport added a subscriber: Unknown Object (MLST).

Unfortunately this report is not very useful because it does not describe the problem well - no definitions of "slow" or on which wikis this happens.
If you have time and can still reproduce the problem, please read https://www.mediawiki.org/wiki/How_to_report_a_bug and add a more useful description to this report, plus a specific example. Profiling info from your browser's developer tools also welcome.

Not sure what is unclear.

That the server is sending the file slower then thumb.php.

thumb.php *is* the server. Maybe you could describe steps to reproduce, what happens, and what you would expect to happen?

FWIW, we are measuring loading times, and compared to file page loading times, they seem to be twice as fast.

Opening a file via filedescriptionpage or thumb.php it loads quick. But opening a file in MV it takes some seconds longerer to load.

Taking a random example from the [[mw:Lightbox_demo]] page:

Clicking on Common_Kingfisher_Alcedo_atthis.jpg, the loading time takes a little less than two seconds. After disabling MediaViewer and clicking on the thumbnail, the image takes a little over 3s to appear (domready event is at 3.5s). This is on Chrome 35 with an 1920x1080px monitor, with warm caches (I have looked both at the file page and the MediaViewer display recently).

(In reply to Steinsplitter from comment #4)

Opening a file via filedescriptionpage or thumb.php it loads quick. But
opening a file in MV it takes some seconds longerer to load.

Please provide clear, specific steps to reproduce that anybody else could follow (I have no idea how to test that the "server is sending the file slower then thumb.php"), plus please provide performance data if possible (developer tools in your browser) and browser information, so we can at least try to have comparable results with similar test setups.

You like that volonteers are searching the error for you payed staffer? ...

No comment, Closing this as WONTFIX and dropping a not onwiki that the WMF don't like to fix it.

Oft habe ich den Eindruck die unbezahlten Volonteers sollen die Arbeit für Staffer machen.
thumb.php & Standard Ansicht liefert eine schnellere Ausgabe wie MV. Bei mv dauert es einige Sekunden länger. Das ziel der WMF war schnellere Auslieferung (Welche auch immer optimiert werden sollte - Somit sollten solche Reports hilfreich sein).
Wenn ich eine Dateibeschreibungsseite aufrufe ist diese Sofort da. Beim MV dauert es Sekunden biss ein Klares Bild erscheint. Kann an der JS bastlerei liegen die verbessert werden könnte (?).

Dass thumbs.php nicht der Server ist sonder nur ein Scipt was thumbs ausliefert (z.B. ?f &w=80&p=40) leuchtet mir ein, Ich denke Tisza Gergő was genau von was ich spreche.

Wie auch immer, es ist nicht der Browser. In FF, IE und Chrom ist es gleich...
Ich hab das Problem auch auf dewiki gelesen (habe den Link jetzt nicht bei Hand)

Weil die WMF schon zich Geld für sinnlos Statistiken usw. ausgibt dürfte es das kleinste Problem sein in das Problem rein zu gucken.

Die WMF verliert immer mehr das Vertrauen der Community in der Art der Antwort & Entscheiden. Die WMF soll für die Community da sein, die WMF ist kein Wirtschaftsunternehmen mit einem "Chef" - oft habe ich den Eindruck es sei eine und mach nur das was Sie will. Ich meine damit nicht die ganze. Aber im Tech bereich läuft eindeutig einiges schief, und wenn jemand das Gegenteil behauptet sollte er sich mal onwiki Diskussionen angucken.
Jetzt wo MV der Communety aufgezwungen wurde ist es das mindeste was man erwarten darf, dass er Einwandfrei Funktioniert.

We run automated tests to measure loading time via MediaViewer and the file page, and MediaViewer is quite a bit faster:
http://multimedia-metrics.wmflabs.org/dashboards/mmv#media_viewer_vs_file_page-graphs-tab

We also collect real-life data which shows MediaViewer to be faster as well.

Those measurements could be wrong or misleading (statistics is hard and the team does not have much experience with them), I wouldn't place a huge amount of confidence in them, but I would certainly trust them over anecdotal reports that people refuse to reproduce.

Anyway, if someone is interested in providing detailed speed reports, [[mw:Multimedia/Media_Viewer/Speed_reports]] has some instructions.

Re: thumb.php, MediaViewer uses it the same way the file page does (it requests the thumbnail file directly, if it doesn't exist, the 404 handler forwards the request to thumb.php which generates the file).

I don't think it's helpful for this bug in order to get fixed to turn it into a high-level "WMF vs community" issue out of frustration that somebody cannot reproduce the problem that you are facing.

(In reply to Steinsplitter from comment #7)

You like that volonteers are searching the error for you payed staffer? ...

It's not about what I "like" or not, it's about clear steps to reproduce the problem because otherwise the problem can neither be investigated nor fixed. This is pretty unrelated to developers being paid or not -- unpaid developers would face exactly the same problem.
I do know that I would like if all bugs were easy to reproduce. Unfortunately that's often not the case, so it is crucial that users help developers through the diversity of systems in use. In software development there are gazillions of configurations and factors that influence problems (networks, browser behaviors, ...) and developers cannot emulate every single configuration via testing.
See "Configuration management" of page 3 in http://www.cyrius.com/publications/michlmayr_hunt_probert-quality_practices_problems.pdf if you trust science.

As you wrote in comment 8 that you and others are successful in reproducing the problem (while Tisza and I unfortunately have not been), it would be great if a tech-savvy user who experiences this problem could use the browser's developer tools (network performance / loading times) to provide some actual data.

Reopening because we still haven't agreed on the problem that must be fixed/wontfixed.

Steinsplitter, all what Andre and Gergő are asking for is a description of how to reproduce the problem, step by step, so others can reproduce the bug:

https://www.mediawiki.org/wiki/How_to_report_a_bug#Quick_recommendations_for_reports

They could not find a way to reproduce the problem. If someone can, please add the details here. Thank you.

(In reply to Quim Gil from comment #12)

Steinsplitter, all what Andre and Gergő are asking for is a description of
how to reproduce the problem, step by step, so others can reproduce the bug:

https://www.mediawiki.org/wiki/
How_to_report_a_bug#Quick_recommendations_for_reports

They could not find a way to reproduce the problem. If someone can, please
add the details here. Thank you.

Meine Antwort war Klar genug. Was wollt ihr noch?

Klarer geht es kaum. Ich habe den Eindruck ihr wollt mich nicht verstehen.
Ich habe den Eindruck ihr wollt mir die Wörter im Mund umdrehen.

(In reply to Andre Klapper from comment #10)

I don't think it's helpful for this bug in order to get fixed to turn it
into a high-level "WMF vs community" issue out of frustration that somebody
cannot reproduce the problem that you are facing.

Mit Verlaub, aber ihr solltet lieber gucken woran es liegt anstatt mit nonsense like "WMF vs community" zu kommen.

To make it clear, i have NO PROBLEM wit the WMF. Andres comment "WMF vs community" is complety nonsense.

I stop commenting here and will notify the communety abut your collaboration.

Have a nice day.

Summary of this report:

(In reply to Steinsplitter from comment #0)

MV is slower then thumb.php...

It takes too long to load this should be improved.

MediaViewer is faster than page file render in most cases, according to Gergő's manual test -- comment #5 -- and the measurements at http://multimedia-metrics.wmflabs.org/dashboards/mmv#media_viewer_vs_file_page-graphs-tab

That graph has an exceptional peak on July 10 and Steinsplitter created this report on July 11. Maybe this is a coincidence, or maybe during some hours something went wrong, and this is what is being reported here?

Then again the subject talks about "thumb generation", so maybe this is something different.

I would say, let's wait for more feedback from other people a few more days, hopefully following the recommendations at [[mw:Multimedia/Media Viewer/Speed reports]].

PS: Steinsplitter, don't be upset, all we share the same interest in displaying images to our users with good performance. I'm also sorry for not being able to answer properly in German, although I can read it well enough.

Steinsplitter, what connection / how much bandwidth do you have?

It's not my connection. Maye it is that slow pc's have the problem to process all the JS..

You might want to elaborate why you think "it's not your connection" then, if we don't want to spend more time with some vague "maybe"s and never fixing something here (in case there is something to fix).

The network tab of the developer toolbar of most browsers displays a waterfall diagram; a screenshot of that diagram could help identify the source of the problem.

Gilles subscribed.
Steinsplitter claimed this task.

This seems resolved, i asked other users and the thumb loading time seems fine.