Difference between revisions of "Cluster wikiload project"
From Teknologisk videncenter
m |
m |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
=Purpose= | =Purpose= | ||
The purpose of this project is to build a distributed program which run on several workstations loading a Wiki server farm. The aggregated load from all workstations can stress the serverfarm and gather information to get idea of how the serverfarm performs. | The purpose of this project is to build a distributed program which run on several workstations loading a Wiki server farm. The aggregated load from all workstations can stress the serverfarm and gather information to get idea of how the serverfarm performs. | ||
== Limitations == | == Limitations == | ||
This is not a program to measure the performance. The time needed to build such a system exceeds the time at hand.<br/> | This is not a program to measure the performance. The time needed to build such a system exceeds the time at hand.<br/> | ||
| − | Another limitation is that its targeted to [www.mediawiki.org MediaWiki] and not as a general workload framework. Though I will try and separate the skeleton from the MediaWiki stuff, to make it easier to implement in other environments. | + | Another limitation is that its targeted to [http://www.mediawiki.org MediaWiki] and not as a general workload framework. Though I will try and separate the skeleton from the MediaWiki stuff, to make it easier to implement in other environments. |
| + | |||
== Name == | == Name == | ||
| + | [[Image:Lobster.gif|right|200px|thumb]] | ||
To refer to the project it needs a name. I think I will call it Lobster. | To refer to the project it needs a name. I think I will call it Lobster. | ||
| − | + | ||
=How it works= | =How it works= | ||
A Lobster Management Station (LMS) will control a number of Lobster clients (LC), telling them how to load the server. From the LMS you set how the LC's should load the serverfarm they willreturn the worload results to the LMS, where it will be presented to you. | A Lobster Management Station (LMS) will control a number of Lobster clients (LC), telling them how to load the server. From the LMS you set how the LC's should load the serverfarm they willreturn the worload results to the LMS, where it will be presented to you. | ||
== Implementation == | == Implementation == | ||
Because of the tight time schedule I've decided to implement it using Perl and the following modules. | Because of the tight time schedule I've decided to implement it using Perl and the following modules. | ||
| + | == LMS == | ||
| + | * Moose For object orientated. - Perhaps | ||
| + | * IO::Socket::Multicast for the LMS auto discovering the LC's. (No time, needs stuff compiled in on Windows) | ||
| + | * [[Perl_POE| POE::Compont::Server::TCP]] as multitasking TCP server | ||
| + | * TK for making a GUI on the LMS. (Takes a long time. Perhaps I will just use Curses also here) | ||
| + | * Storable for saving results to disk. (A bad idea but very fast to implement.) | ||
| + | |||
| + | ==LC's== | ||
| + | * Moose For object orientated. - Perhaps | ||
* WWW::Mechanize as the HTML Client engine. | * WWW::Mechanize as the HTML Client engine. | ||
* POE::Session as the multitasking engine on the LC's to load the serverfarm | * POE::Session as the multitasking engine on the LC's to load the serverfarm | ||
* Curses for controling the Screens of the LC's (Perhaps also for the LMS) | * Curses for controling the Screens of the LC's (Perhaps also for the LMS) | ||
| − | * | + | |
| − | * | + | = Project Schedule= |
| + | == LMS - Lobster Management Station == | ||
| + | === Skeleton === | ||
| + | Built as a statemachine | ||
| + | |||
| + | == LC - Lobster clients == | ||
| + | === Skeleton === | ||
| + | *State 1: Connect to the LMS then go to state 2 | ||
| + | *State 2: Wait for orders from LMS then go to state 3 | ||
| + | ** Keepalive packets every 10 seconds else go to state 1 | ||
| + | *State 3: Fetch one page (Several attemps with 10 Seconds timeout) from serverfarm if OK go to state 10 else go to state 4 | ||
| + | *State 4: Report Error to Connect to LMS go to state 3 | ||
| + | *State 10: Start monitor session go to state 11 | ||
| + | ** monitor session get results from Workload session and report every 10 sec. to LMS | ||
| + | *State 11: Start each Workload sessions in state 20. | ||
| + | *State 20: Report ''I am alive and session number N'' to ''monitor session'' if receive ''acknowledge'' within 2 seconds from monitor go to state 21 else die. | ||
| + | *State 21: Send keepalive every 5 second to ''monitor session'' if three sent without ''acknowledge'' send ''die'' and then die. | ||
| + | ** Load server and report in keepalive packets load. | ||
| + | [[Category:Perl]][[Category:Cluster]] | ||
Latest revision as of 15:59, 2 April 2009
Contents
Purpose
The purpose of this project is to build a distributed program which run on several workstations loading a Wiki server farm. The aggregated load from all workstations can stress the serverfarm and gather information to get idea of how the serverfarm performs.
Limitations
This is not a program to measure the performance. The time needed to build such a system exceeds the time at hand.
Another limitation is that its targeted to MediaWiki and not as a general workload framework. Though I will try and separate the skeleton from the MediaWiki stuff, to make it easier to implement in other environments.
Name
To refer to the project it needs a name. I think I will call it Lobster.
How it works
A Lobster Management Station (LMS) will control a number of Lobster clients (LC), telling them how to load the server. From the LMS you set how the LC's should load the serverfarm they willreturn the worload results to the LMS, where it will be presented to you.
Implementation
Because of the tight time schedule I've decided to implement it using Perl and the following modules.
LMS
- Moose For object orientated. - Perhaps
- IO::Socket::Multicast for the LMS auto discovering the LC's. (No time, needs stuff compiled in on Windows)
- POE::Compont::Server::TCP as multitasking TCP server
- TK for making a GUI on the LMS. (Takes a long time. Perhaps I will just use Curses also here)
- Storable for saving results to disk. (A bad idea but very fast to implement.)
LC's
- Moose For object orientated. - Perhaps
- WWW::Mechanize as the HTML Client engine.
- POE::Session as the multitasking engine on the LC's to load the serverfarm
- Curses for controling the Screens of the LC's (Perhaps also for the LMS)
Project Schedule
LMS - Lobster Management Station
Skeleton
Built as a statemachine
LC - Lobster clients
Skeleton
- State 1: Connect to the LMS then go to state 2
- State 2: Wait for orders from LMS then go to state 3
- Keepalive packets every 10 seconds else go to state 1
- State 3: Fetch one page (Several attemps with 10 Seconds timeout) from serverfarm if OK go to state 10 else go to state 4
- State 4: Report Error to Connect to LMS go to state 3
- State 10: Start monitor session go to state 11
- monitor session get results from Workload session and report every 10 sec. to LMS
- State 11: Start each Workload sessions in state 20.
- State 20: Report I am alive and session number N to monitor session if receive acknowledge within 2 seconds from monitor go to state 21 else die.
- State 21: Send keepalive every 5 second to monitor session if three sent without acknowledge send die and then die.
- Load server and report in keepalive packets load.