Last modified: 2013-03-13 12:25:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T37326, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35326 - File deletion slowness
File deletion slowness
Status: RESOLVED WORKSFORME
Product: Wikimedia
Classification: Unclassified
Media storage (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance, testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-19 17:10 UTC by Victor Vasiliev
Modified: 2013-03-13 12:25 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Victor Vasiliev 2012-03-19 17:10:23 UTC
Deletion of file takes ~8 seconds. I got numerous reports about that from ru.wikipedia and was able to reproduce that on test.wikipedia as well. Please investigate.


Profiler output (all entries >1%):
<!--
100.00% 7.811909      1 - -total
 98.61% 7.702979      1 - MediaWiki::main
 96.82% 7.563558      1 - MediaWiki::performRequest
 96.66% 7.550731      1 - MediaWiki::performAction
 34.97% 2.731953      2 - FileBackendStore::doOperationsInternal
 29.91% 2.336342      1 - FileBackendStore::deleteInternal
 15.57% 1.216589      1 - FileBackendStore::doClean
 13.43% 1.049439      1 - LocalFileDeleteBatch::execute
  5.64% 0.440752      1 - AbuseFilterHooks::onArticleDelete
  5.63% 0.439517      1 - AbuseFilter::filterAction
  5.62% 0.438832      1 - AbuseFilter::checkAllFilters
  5.36% 0.418516      3 - LockManager::unlock
  3.81% 0.297513      3 - LockManager::lock
  3.35% 0.261549    258 - MWMemcached::get
  2.23% 0.174238     52 - AbuseFilter::checkConditions
  2.22% 0.173525     51 - DatabaseBase::query-master
  1.97% 0.153577     11 - Title::getUserPermissionsErrorsInternal
  1.95% 0.152442      2 - FileBackendStore::doPrepare
  1.75% 0.136925      1 - MediaWiki::finalCleanup
  1.70% 0.132838      1 - FileBackendStore::moveInternal
  1.68% 0.131577      1 - OutputPage::output
  1.52% 0.119060      1 - Output-skin
  1.52% 0.118848      1 - SkinTemplate::outputPage
  1.51% 0.118343      2 - CentralAuthHooks::onUserGetRights
  1.38% 0.108028     46 - AbuseFilterParser::doLevelFunction
  1.36% 0.106230      1 - wmfPurgeBackendThumbCache
  1.09% 0.085180      5 - User::getEffectiveGroups
  1.03% 0.080707      9 - User::load
  1.02% 0.079321      1 - FileBackendStore::doSecure
Comment 1 Victor Vasiliev 2012-03-19 17:13:44 UTC
Just a note: the above profiling output is for [[testwiki:File:Teeeest.png]]. I also tested it with File:Gpl-dos.png, and it was even more than 8 secs.
Comment 2 Sam Reed (reedy) 2012-03-19 22:03:40 UTC
I thought this was a dupe, but I can't see it. There is bug 34717 which is slow file reversion. If they weren't related I'd be rather suprised

CC'ing Aaron and Ben
Comment 4 Andre Klapper 2012-11-14 13:17:28 UTC
Victor: Is this still a problem nowadays, or could this be closed as RESOLVED WORKSFORME?
Comment 5 Victor Vasiliev 2012-11-14 15:03:35 UTC
I am not exactly sure. I do not remember, it was probably either temporary server issue (which means you can close it), or an issue which works only with a certain class of files (which probably means debugging).
Comment 6 Andre Klapper 2013-03-13 12:25:33 UTC
No indication that problem still exists - please feel free to reopen if there are issues again.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links