https://bugzilla.wikimedia.org/show_bug.cgi?id=32432
--- Comment #10 from Tim Starling <[email protected]> 2012-01-03 23:45:37 UTC --- Marking invalid. The supplied test case works for me. Yes, it's possible that at some point in the past, thumbnails were slow to render, but urgent site issues should be discussed on IRC while they're actually happening, not on Bugzilla 6 weeks after the fact. Maybe at some point in the future we will have sufficient historical service time data to let us confirm or maybe even diagnose this sort of thing after the fact. But at the moment we are mostly limited to real time analysis. (In reply to comment #6) > Should not be to hard to reproduce this. Currently it happens all the time for > all new images or simply when creating a gallery in a size that was never > rendered before. For example, go to > http://toolserver.org/~daniel/WikiSense/Gallery.php?wikifam=commons.wikimedia.org > and switch to 250 images per page. The browser should limit concurrency to about 5, so say if it takes 2 seconds per image, then that would be 1 minute 40 to load all images. Is that what you see? We only have 60 threads on 48 cores for the whole image scaling cluster, so obviously if you want 250 images at a time, it's going to take a while, even with unlimited client-side concurrency. If you don't want it to be slow, then don't do that. Maybe ms5 will hit an I/O limit before we get to 60 threads, but it's clear from the profiling data that ms5 is not permanently in such a state. The average thumb.php service time measured by MediaWiki is only 156ms. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
