QA/Sync/Test Plan/grinder tests/technical documentation: Difference between revisions

QA/Sync/Test Plan/grinder tests/technical documentation (view source)

209 bytes added , 20 June 2011

89

edits

@@ Line 12: / Line 12: @@
 *** REST api we can perform the same steps to communicate with sync as we can to communicate with the database
-=== Important features of the sync system ===
+=== Current Architecture ===
-* Load Balancer - Zeus
+* load-auth.services
-** Will protect us from connection overrun
+** Current load Target
-** Questions about how it responds under high load condition and how firefox responds to that
+** No Captcha
-** Extremely scalable (will likely never be a bottle neck)
+** No mechanism for creating users
-* Back end application
+* client[4-9].scl2.svc
-** Currently in PHP, will be migrated to python
+** Runs grinder load generater
-** Questions about through put of data
+** Has jython installed
-* Database Server
+** Direct access to load-auth.services
-** Currently has a large cache (this means we need a lot of tests before we are truly in a production type environment)
+* Console Controller (any linux/windows computer connected to MPT)
+** Controls test execution
+** Has created a reverse ssh tunnel into the above grinder client so that the clients can see the grinder console
+See the following link for a graphical picture of how grinder systems are setup: [http://grinder.sourceforge.net/g3/getting-started.html#The+Grinder+processes| The Grinder Processes]
+n.b. In terms of grinder lingo client[4-9].scl2.svc are agents with multiple workers each.