Mailing List Archive: Wikipedia: Wikitech

secure slower and slower

1 2

View All

Index | Next | Previous | View Threaded

william.allen.simpson at gmail

Jul 18, 2009, 10:06 PM

Post #26 of 28 (292 views)
Permalink

Re: secure slower and slower [In reply to]

Aryeh Gregor wrote:
> For what it's worth, I also don't think SSL is worthless. I don't
> personally see any reason to go out of my way to use it, and think
> it's a little odd for someone else to do that given the marginal
> benefit it would provide by any metric. But I'd definitely agree that
> if it could be enabled for all Wikipedia users by *default* that would
> be great. A small benefit times millions of users can be a very big
> benefit. An ideal Internet would encrypt *and* sign all
> communications with no opt-out. (One of the things I'm looking
> forward to if Google Wave takes off!)
>
I'm rather a secure Internet kinda guy, having written many of the
IETF pre-SSL authentication and encryption proposed standards; the ones
that the FBI and NSA opposed, and hit me with an investigation for
treason.... Folks sometimes forget (or never knew) that SSL was
weakened by design....

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!

brion at wikimedia

Jul 19, 2009, 11:38 AM

Post #27 of 28 (289 views)
Permalink

Re: secure slower and slower [In reply to]

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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

william.allen.simpson at gmail

Jul 19, 2009, 12:44 PM

Post #28 of 28 (292 views)
Permalink

Re: secure slower and slower [In reply to]

Brion Vibber wrote:
> Note that its CPU load is consistently pretty low.
>
I added the graph as an attachment to the bug report instead. That
week view really smooths things out. Last night at one point, it took
about 5 minutes for anything.... 2 minute saves were common.

> 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.
>
I've not really tried the non-SSL much, except running scripts, which
still see a fair number of lag messages. Although nothing like last
weekend, with dozens of lag messages on every attempt....

Thank heavens (and its helpers) that's clearing up! But I'd started this
thread before that problem cropped up.

> 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.)
>
Pretty much vanilla options, except setting my date formats to yyyy-mm-dd.

I'll try some regular logins, and see whether that's any different.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads