MediaWiki Performance Optimization by Reducing Traffic and Server-side Calculation
 | This page is kept for historical interest. Any policies mentioned may be obsolete. If you want to revive the topic, you can use the talk page or start a discussion on the community forum. |
Personal Info
[edit]Name
- Shtriter Andrew
- Shtriter@gmail.com
ICQ
- 306035039
Project Title
[edit]- MediaWiki Performance optimization
Synopsis
[edit]The aims of the project are:
- Improve UI of Wiki-based sites – change MediaWiki_look_and_feel taking into consideration Web 2.0 requirements.
- Optimize Browser-Server Dialogue that will help to avoid unnecessary server calculations, obviate conflicts of the simultaneous editing, decrease use of traffic and speed up page downloads and preserve existing caching scheme.
Benefits
[edit]I will create new monobook-based skin that will be divided into separate blocks. Each of them will be able to talk with server using the Client API to get important data from server without reloading a page. That approach will also enable many actions to be done avoiding server interconnection (“Printable version”, “Permalink”…) or only sending results to server (password and upload dialogs, view/edit mode switching and so on).
Drawbacks
[edit]- User will not be able to save wiki page (as static html), straightforwardly, since the separated xml data may not be saved. --Ans 08:07, 8 May 2008 (UTC)
- May be no problem with Firefox, since it save the current rendered html contents, but I'm not sure with IE. --Ans 08:16, 8 May 2008 (UTC)
- A solution may be to provide non-AJAX/static-html link as a complement to printable link, but this still be non-straightforward in saving page. --Ans 11:54, 8 May 2008 (UTC)
- Another solution may be to include those data in <... src=...> tag. This may be possible with json data format, but not yet test. --Ans 05:14, 9 May 2008 (UTC)
Deliverables
[edit]- Query JS Library – set of functions used for Browser-Server Dialogue.
- Advanced XHTML skin – monobook-based skin with the improved UI: various js-powered popup tooltips and hideable menus and dynamic customizable user color schemes. Skin will be written in Strict XHTML with external *.js files and stylesheets that will be suitable for using as separate library.
- Documentation – comprehensive description of «Query JS library» and skin-creation Guidelines.
Project Details
[edit]- The Library will be written in JavaScript and will implement Client API query.php. Rarely used functions will be downloaded on-demand. If some extra features are requested (such as client-side XSLT, smart history and so on) the Library can use some 3-rd party’s libraries.
- Advanced XHTML skin due to Wiki Skins format will be written in PHP and AJAX. It will be highly integrated with Query JS Library and use it for server interconnection. I will change default monobook skin in order to provide multi-stage download and simultaneous requests.
Project Schedule
[edit]| Step | Description | Results | Duration |
|---|---|---|---|
| 1 | Getting in touch with mentor. Choosing desirable way of project development | Requirements specification, wish-list and feature requests | 1-3 days |
| 2 | Creation of the JavaScript library that uses query.php and/or XML representation of wiki markup for server requests and transforms received data to XHTML | Query JS Library | 7-21 |
| 3 | Adaptation of the default monobook skin to the new requirements. This step will also include blocks interaction implementation and will be characterized by the wide use of the new Query Library that was created on the previous step. | Advanced XHTML monobook-based skin (UI functions may be released separately if necessary) | 7-21 days |
| 4 | Smart UI creation (i.e. menus, hints, dynamic styling and so on). | 7-21 days | |
| Total: | Complete solution for MediaWiki Performance optimization. Each step includes time for documentation and debugging | Registered project at SourceForge that will include all-in-one Performance optimization solution and separate archives with skin and lib(s) | 22-66 days |
- Notes:
- Minimal project duration is possible, assuming that project will take not less the 8 hours of intensive development each day. Maximum can be easily calculated taking into consideration that such extreme development is not always possible and as known all projects take about pi times longer to complete. In any case the deadlines will not creep up on me.
BIO
[edit]I am third year student at the Togliatty State University, Russia. My major is Automation of technological processes, Physicotechnical institute. I have more then 7 years of programming experience in (Object)Pascal, VB and C++. After getting a job in my university I’ve started the development of internal AIES php/mysql project in the small team headed by experienced developers. The project was successfully finished after the year of intensive development. It led to my first career promotion and intensive studying of other web-programming languages: perl and python. I gained useful experience not only in web-development and understood the advantages of using Linux and version control system for programming. About one year ago I’ve began to use AJAX and XSLT in my web-developments.
My brief summary is available at User:Shtriter.
At a first time I've used Wikipedia as educational resource for getting necessary information. AJAX and List of portable applications pages had a great impact on me, in spite of I haven't submitted my ideas until the beginning of SoC 2006.
About six month ago I've started the development of the Educational Environment - prototype of my graduate work. My tutor and I decided that MediaWiki on a stick will be the best engine for it.
Though I do share F/OSS ideas, I haven't previously contributed to open source projects because I have no idea what foundation would like to work with me. I'm sure that my programming experience is enough to be able to complete the project, so Summer of Code is my real chance and my great opportunity.
I have chosen WikiMedia Foundation as my mentor due to following reasons:
- I fell in love with the idea to make something useful for the world biggest online dictionary! It will be a great pleasure for me to work at that project.
- The experience, gained while taking part at the project, will be very important for my graduate work because MediaWiki is essential part of it.
This is my first proposal and I'm not willing to sign in to other projects because none of them compares to MediaWiki Performance optimization project.
Design
[edit]First phrase
[edit]This phrase focus only on the parsed content.
- query: http://en.wikipedia.org/wiki/Main_Page
- return sidebar, header, footer, except body content part.
- body content part will be something like,
<div id=bodyContent><h3 id=siteSub>From Wikipedia ...</h3><...>
<div id=text-Content>loading content ...</div>
</div>
- body content part will be something like,
- javascript fetch the text data from, http://en.wikipedia.org/w/api.php?action=parse&title=:Main_Page&text={{:Main_Page}}&format=xml&prop=text
- javascript write text data into <div id=bodyContent>.
- return sidebar, header, footer, except body content part.
In this phrase, the text data will be cachable independently of the login and anonymous user. (The hide/show edit section doesn't affect the text data, since it is controlled by css) But the api.php need to send Last-Modified: header, and properly handle If-Modified-Since request. Unfortunately, the current api.php on wikipedia doesn't handle this.
Prerequisite
[edit]- api.php need to send Last-Modified: header, and properly handle If-Modified-Since request. Without this this phrase will not improve any performance.
Problem
[edit]- api.php?action=parse can't determine the variable {{PAGENAME}} and its family, since it doesn't accept page title as input, rather it accept the wiki text to be parsed. (See http://test.wikipedia.org/w/api.php?action=parse&text={{:User:Ans/api.php_variables_test_case}}&format=xml&prop=text and http://test.wikipedia.org/wiki/User:Ans/api.php_variables_test_case, respectively)
- api.php always set the page title to "API".
Done: This is solved by putting title variable.
- When prop=templates (for action=parse&text={{:Main Page}}), it will always include {{:Main Page}}, in the templates list. (prop=templates may be used in the later phrase)
- Done: Use action=query&prop=templates instead --Ans 11:29, 8 May 2008 (UTC)
Question
[edit]- Does user setting of hide/show edit section affect the content of text data?
- Done: No, since the appearance of edit section is controlled by css.
- Does user setting of "red link format", "justify paragraph", "auto-number heading", "show/hide TOC", affect the content of text data? --Ans 11:47, 8 May 2008 (UTC)
- ...
- How much this will improve the traffic on wikipedia? --Ans 12:14, 8 May 2008 (UTC)
- Need to check the statistics of the visiting between login and anonymous user --Ans 12:14, 8 May 2008 (UTC)