>>>> Christian Boltz <opensuse@cboltz.de> 8/21/2012 12:08 PM >>>
>Hello,
>
>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.