Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Tue, 19 Jan 2016 18:40:45 -0600
schrieb David Kowis <dkowis AT shlrm.org>: 

> On 01/19/2016 02:23 AM, Thomas Orgis wrote:
> > Hi,
> > 
> > about that new cheaper server … that kind of hardware/setup is it? I was
> > wondering why mediawiki.sourcemage.org is that darn slow. It's also
> > around a second after the initial loading of content that the style
> > sheet seems to be arriving and then the whole page changes. Stealth's
> > site is so much more snappy:-/ Wikipedia itself also is faster and I
> > don't see the late style arrival. What's the difference? Is
> > mediawiki.sourcemage.org under some DoS attack?  
> 
> The hardware isn't bad, although I don't know the exact specifications.
> I am running the pgsql, mediawiki, and bugzilla all on the same server.
> We can probably get more ram for this VM if this is the way we want to
> run it, or we can move the database server to a different VM. There's
> some flexibility there.

Since there is not much data in there (I suppose), I doubt that a huge
amount of RAM would change things. Or is the VM at its RAM limit? No
disk cache and thus slow access times? I am not trying to diss your
setup, I am truly wondering why …

shell$ LANG=C time wget http://beta.sourcemage.ru/
--2016-01-20 09:25:35--  http://beta.sourcemage.ru/
Resolving beta.sourcemage.ru (beta.sourcemage.ru)... 85.25.127.80
Connecting to beta.sourcemage.ru (beta.sourcemage.ru)|85.25.127.80|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 8728 (8.5K) [text/html]
Saving to: 'index.html.2'

index.html.2              100%[======================================>]   
8.52K  --.-KB/s   in 0.003s 

2016-01-20 09:25:35 (3.27 MB/s) - 'index.html.2' saved [8728/8728]

0.00user 0.00system 0:00.09elapsed 6%CPU (0avgtext+0avgdata 15424maxresident)k
0inputs+24outputs (0major+231minor)pagefaults 0swaps

… this page itself arrives in 3 ms (90 ms total runtime), while …

shell$ LANG=C time wget http://mediawiki.sourcemage.org/
--2016-01-20 09:25:43--  http://mediawiki.sourcemage.org/
Resolving mediawiki.sourcemage.org (mediawiki.sourcemage.org)... 72.29.99.116
Connecting to mediawiki.sourcemage.org 
(mediawiki.sourcemage.org)|72.29.99.116|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html.3'

index.html.3                  [   <=>                                 ]  
37.97K  51.5KB/s   in 0.7s   

2016-01-20 09:25:44 (51.5 KB/s) - 'index.html.3' saved [38882]

0.00user 0.00system 0:01.43elapsed 0%CPU (0avgtext+0avgdata 14816maxresident)k
0inputs+80outputs (0major+229minor)pagefaults 0swaps

… this one needs 700 ms for transfer (1430 ms total). When I'm in the
browser, there is another second until the style arrives and the page
changes layout. There is some huge initial delay before anything is
delivered. There is both a moment of hesitation before the "200 OK" and
slower transfer of the data after that, even accounting for the
differing size.

> However, as I mentioned in the previous email, our PHP spell is out of
> date, and does not include the useful caching stuff that would make
> mediawiki perform substantially faster.

Point taken, that is something we should fix, then.

> get something done, and out there first, as a test run to see how well
> it worked putting some content in there.

Understood. As long as we got some routes to optimise things. And I
hope one can really skin this cat so that it looks more like Stealth's
site and not like Wikipedia.

> It's extremely fast for anonymous users

Not as it is now. I didn't try to login yet. Are accounts migrated?

> appreciate some help with the php spell though). I think it probably
> wouldn't hurt to go all the way to php 7 and get that working.

The spell should updated in any case (not that I am that much
interested in PHP myself, though). So that work is not wasted even if
Stealth reappears.

> Since there hasn't been any objection to my earlier proposal, I'm
> going to start the wheels in motion to move to the things that I've
> set up on the distro hardware, so at the least, we don't have a
> "Sorry it's broke" page.

OK, any page is better than that.

> With regards to bugzilla and importing bugs,
> I'm still not fully convinced that ancient,

I am growing to accept that the old bugs are not of much use. I'd like
to have an archive for referencing old fixed bugs, since those are
mentioned in commits and HISTORY files, so we know why we did something
there. But the live instance of bugzilla does not really need those.

But can we start counting at a point > 1 so that bug numbers don't get
repeated?

> I do not wish to keep
> the same bugzilla structure as before, as that doesn't make any sense
> to do at all with the type of organization we are right now.

Agreed. Simpler bugzilla setup (just make sure we got those latest
security fixes in there … CGI.pm and all) is good.
 

Alrighty then,

Thomas

Attachment: pgpA2fOZX2TJ_.pgp
Description: Digitale Signatur von OpenPGP