[wp-trac] [WordPress Trac] #10611: Support Partial core upgrades
WordPress Trac
wp-trac at lists.automattic.com
Tue Oct 6 14:37:43 UTC 2009
#10611: Support Partial core upgrades
-----------------------------+----------------------------------------------
Reporter: dd32 | Owner: dd32
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: Upgrade/Install | Version: 2.9
Severity: normal | Keywords:
-----------------------------+----------------------------------------------
Comment(by Denis-de-Bernardy):
> One thing that many people are not sure about is where the main
bottleneck is
> * Downloading the large Zip file
> * The Zip Decompression (This is mainly memory usage IMO)
> * The IO time
> * The 2nd IO time
>
> Personally i think its mainly the IO..
Oh, I can give you some feedback on that. Keep in mind that my own zip is
7M+. :-P
* download takes a few seconds
* cleaning up after a failed install is very very very slow (see #10913)
* unzip is *very* slow and resource hungry
* copying actually is pretty fast
* cleaning up is, again, very very very slow
What frequently happens on my end with WP 2.8.x sites one of the
following:
1. the zip gets downloaded
2. unzipping occurs, takes a lot of time, FTP times out about when it's
done
3. WP starts to copy, fails due to the FTP time out, and bails
4. WP can't clean-up
5. User tries again
6. the zip gets downloaded
7. FTP times out during the clean-up
8. User tries again
9. the zip gets downloaded
10. FTP finishes up the clean-up
11. Return to step 2 (until user decides it's hopeless)
The way I work around it is by hooking into update_feedback. On each
feedback, I force flush the output so the user gets some kind of feedback.
I then disconnect the FTP (some hosts disallow overriding time-outs,
meaning that #10407 or the newer ticket needs more fixing), I reconnect
the FTP, and I reconfigure the FTP so it times out after 10 minutes on the
host where that works. So far it's pretty successful.
I considered uploading partial zips, but it seemed too risky (can't trust
the version sent by the site, especially after a failed upgrade); the same
goes for having a special file with the md5 of every file. Keeping the md5
in options is no good either -- if a manual upgrade occurs, it breaks.
That is to say, I think it's more important to fix #10913, which is the
main culprit for failed upgrades.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/10611#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list