https://bugzilla.wikimedia.org/show_bug.cgi?id=29111

--- Comment #4 from MWJames <jamesin.hongkon...@gmail.com> 2011-05-24 20:40:55 
UTC ---
We are in the middle to confirming our data but since we didn't want to be
impolite in not responding, please let me introduce some preliminary
information about the test setup.

CONFIGURATION

The configuration follows a standard configuration without particular tweaks
and hacks.

OS

Windows Vista/Japanese Version

PRODUCTION SYSTEM 

MediaWiki    1.16.1 (r80998)
PHP    5.2.13 (apache2handler)
MySQL    5.1.44-community

TEST SYSTEM

MediaWiki    1.17.0beta1
PHP    5.2.13 (apache2handler)
MySQL    5.1.44-community

EXTENSIONS

Various extensions are active but in order to eliminate their influence, we
decided not to test any page content that is referring to one of those
extensions (especially since we are using Semantic Mediawiki, no testing takes
place were data might be effected with this extension) 

CACHE (LocalSettings)

Cache settings have been turned on for both systems.

## Shared memory settings
$wgMainCacheType = CACHE_ACCEL;
#$wgMainCacheType = CACHE_DB;
$wgMessageCacheType = CACHE_ACCEL;
#$wgMessageCacheType = CACHE_DB;
#$wgCacheDirectory = "$IP/cache";
$wgParserCacheType = CACHE_ACCEL;
#$wgParserCacheType = CACHE_DB;
$wgMemCachedServers = array();
$wgUseGzip = true;
$wgEnableSidebarCache = true;
# NO DB HITS!
$wgDisableCounters = true;
$wgMiserMode = true;
# Text cache
#$wgCompressRevisions = true;
$wgRevisionCacheExpiry = 3*24*3600;
$wgParserCacheExpireTime = 14*24*3600;

HARDWARE

Both instances running on the same hardware (implying that the hardware itself
can't be an influencing factor in how performance is altered) 

DATABASE

The database is mirrored from the production system so that both system are
using the same data and data structure.

THE TEST

As for the test, at the time of the testing only one user is active so that the
influence of other user requests are eliminated.

We are not claiming that our test results are sufficient enough that can hold
against a control group (especially by trained IT personal), therefore we only
cite information received from the bowser in how long the page request and
rendering took place. 

We shall test loading time of category pages, special pages as well as newly
created blank pages (eliminating external influence that are beyond Mediawiki
software itself). Those blank pages will be filled with lorem ipsum text to
avoid misunderstanding and inconsistencies.

MEASUREMENT

As for the measurement, we will use a Iron/9.0.600.2 Chrome/9.0.600.2 browser
where the included developer tool will guide us to determine time-lines and
audit reports. Further we will use the time that has been rendered into the
page source itself (eg. <!-- Served in 1.512 secs. -->)

We will not use other tools to measure time or page requests, our main
objective is a comparative study from a user point of view that demonstrates a
difference that occurred while only one variable was altered (Mediawiki
software changed from 1.16.1 to 1.17beta while browser, data and hardware
continued)

IN GENERAL

Certainly we are not particular trained in running IT systems but we are using
Mediawiki for the last three years as internal enterprise and research
database, and we went through several migrations. 

Our hardware might not be particular powerful but until now it was good enough
for the response time we received.

Certainly, we are aware of the fact the 1.17 is running for quite a while on
the Wikipedia platform and testing must have been intense. 

We might have to blame ourself's for insufficient application but as far as we
can tell, and referring to our experience we managed to balance users
satisfaction and maintenance cost while not running a high maintenance server
farm.

For the next post we should provide our results.

We are welcome any suggestions, to improve the test itself.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to