Mailinglist Archive: opensuse-web (64 mails)

< Previous Next >
Re: [opensuse-web] Please update wiki staging server
Christian Boltz <opensuse@xxxxxxxxx> 8/21/2012 12:08 PM >>>

Matthew, can you please check the update on stage again?

Special:Version still doesn't list the ReplaceText extension, and the
print.css also doesn't seem to be included. (In other words: it looks
like you didn't deploy the latest code from the 1.19 git branch.)

My mistake. I didn't realize the new installation was put on different branch.
I just now pulled the changes from there. I get a database error... was there
some SQL that needed to be run with that?

Besides that, the test account opensuse_stage:opensuse_stage (created by
Thomas) doesn't seem to work - I don't get an error message, but I'm not
logged in after (trying to) login.

I'm not sure if this ever worked for me, and Thomas told me on IRC today
<digitltom> cboltz: that seems to be a bug, the login works for the
staging access manager

Any idea what could be wrong with the login?

It seems to work fine on the openSUSE staging blogs and on staging Novell.
Because of the broken database query, I can't try it out on the wikis at the
moment. I'll make sure to check as soon as it's fixed. My guess right now
would be that the login extension is broken with the new version.

Am Dienstag, 21. August 2012 schrieb Matthew Ehle:
[performance issues]
We were actually talking about the stage server, which was taking
something like 30 seconds to load. Turns out that the memcached
server had been turned off, so it was spending all that time to query
something that wasn't running. We flipped it back on, and it's all
fixed now!

That explains it ;-)
Thanks for checking and fixing it!

No problem. It's a huge relief.

have looked into why sometimes the main page doesn't come back. So
far, the main culprit appears to be our ancient load balancer.

Are you seriously telling us that the load balancer makes the wiki
slower? ;-)

Not in general, but it looks like it can drop requests sometimes. We're still
trying to track it down exactly, but that's the most likely candidate right now.

Speaking of that, we are looking at some load balancer options that
can do a lot for us. One vendor can implement SPDY and is capable of
downsampling images on the fly for mobile devices.

Does this really make sense, now that mobile devices start having high-
resolution displays?

I think so. Even high-res phone displays are much lower than your typical
desktop. For example, the 12.2 banner on the wiki home page alone takes up
most of an iPhone 4 screen. Put in the context of the full wiki page, the
image is rendered at maybe half that resolution. Apply that principle to all
the page images, and that's a big difference if you are on a mobile network
trying to bring up a page. Sure, some people might zoom in on the image and
then notice a difference, but for 99% of users, it's going to be worth the
difference in page loading time.

Another is capable of TLS false start, which can cut SSL negotiation
time by 25% or more.

IIRC most of the wiki runs over http, not https - therefore I doubt SSL
negotiation speed is a real problem ;-)

It's about half and half right now. For whatever reason, most of the static
content is hardcoded to be pulled from a secure connection. In fact, I would
propose that we go ahead and turn of SSL for the rest of the wiki. As it
stands, people logged into the forums, wikis, and blogs are vulnerable to
session hijacking, which is only really fixable by encrypting the entire
session. SSL is much less of a performance problem than it used to be, and
using things like SPDY and false start make it completely negligible.
< Previous Next >
Follow Ups