William Allen Simpson wrote: > Anyway, I'm happy to help make Wikipedia somewhat more secure. Here's > a ganglia CPU picture that might explain a little of the problem. I'm > trying to edit off-peak hours, but those peaks are devastating!
Attachments are stripped automatically from this list, so can't see your graph, but here's a link to the Ganglia monitoring page for the server that does the HTTPS proxying for secure.wikimedia.org: http://ganglia.wikimedia.org/pmtpa/?r=week&c=Miscellaneous&h=bart.wikimedia.org Note that its CPU load is consistently pretty low. The secure.wikimedia.org proxy hits the *exact* same backend web servers as everybody else, so editing activity shouldn't be particularly slower unless there's something actually preventing the proxy from reaching the backend that doesn't prevent everybody else going through the non-HTTP proxies from getting there. Personally I haven't noticed any unusual performance browsing and editing through secure.wikimedia.org the last couple weeks versus behavior on the non-SSL view. One thing I will note is that when editing through secure, or when having certain non-default preferences, editing will require at least two backend renders of the page: once with default options to save link data and save default view to the parser cache, then a second time for your options when you reload. If you have all default options, then saving edits to particularly large or template-complicated pages may indeed be slower through secure.wikimedia.org than not. If you have changed options which affect rendering, then it should be about the same either way. (Except for the inherent extra slowness making the SSL connections.) -- brion _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
