[Checkins] SVN: Sandbox/J1m/resumelb/src/zc/resumelb/ - timing-based test fix, spelling fixes
John Murphy
jackie at zope.com
Mon Mar 5 18:28:30 UTC 2012
Log message for revision 124521:
- timing-based test fix, spelling fixes
Changed:
U Sandbox/J1m/resumelb/src/zc/resumelb/lb.test
U Sandbox/J1m/resumelb/src/zc/resumelb/pool.test
U Sandbox/J1m/resumelb/src/zc/resumelb/protocol.txt
U Sandbox/J1m/resumelb/src/zc/resumelb/worker.test
U Sandbox/J1m/resumelb/src/zc/resumelb/zk.test
-=-
Modified: Sandbox/J1m/resumelb/src/zc/resumelb/lb.test
===================================================================
--- Sandbox/J1m/resumelb/src/zc/resumelb/lb.test 2012-03-05 17:52:59 UTC (rev 124520)
+++ Sandbox/J1m/resumelb/src/zc/resumelb/lb.test 2012-03-05 18:28:29 UTC (rev 124521)
@@ -5,7 +5,7 @@
networking aspects of the LB.
An lb takes a set of worker addresses, which it connects to. It
-listens on an address for incoming web requests. You can updare it's
+listens on an address for incoming web requests. You can update its
set of worker addresses at any time.
To test lb behavior, we'll create faux workers the lb can connect to.
@@ -82,7 +82,7 @@
>>> read_message(worker1)
(1, '')
-If we another request for the same host, it will appear on the same
+If we send another request for the same host, it will appear on the same
socket. This time, we'll make a request that provides a large body:
>>> app2 = webtest.TestApp(lb.handle_wsgi)
@@ -326,7 +326,7 @@
>>> workers[0].socket != worker1
True
-It's not in the lb pool yet, because we haven't sent it's resume yet:
+It's not in the lb pool yet, because we haven't sent its resume yet:
>>> len(lb.pool.workers)
1
@@ -339,8 +339,8 @@
2
In the test above, the worker was still listening the whole time.
-Let's Go a bit further. We'll shut down the worker's server as well
-as the worker socket. When the lb gets an error, it sleaps a a second
+Let's go a bit further. We'll shut down the worker's server as well
+as the worker socket. When the lb gets an error, it sleeps a a second
after failed attempts. We can change this by setting a class variable
that exists primarily for testing. We'll change it on the lb.
@@ -400,7 +400,7 @@
>>> lb.set_worker_addrs([w.addr for w in workers])
Removing a worker doesn't disconnect it, but it will prevent it from
-being reconnected if it disconnects in it's own.
+being reconnected if it disconnects on its own.
>>> gevent.sleep(.01)
>>> len(lb.pool.workers)
@@ -412,7 +412,7 @@
>>> len(lb.pool.workers)
2
-Because the lb didn't reconnect, our's socket is till the one from
+Because the lb didn't reconnect, our socket is still the one from
before that we closed:
>>> out.socket is outsocket
Modified: Sandbox/J1m/resumelb/src/zc/resumelb/pool.test
===================================================================
--- Sandbox/J1m/resumelb/src/zc/resumelb/pool.test 2012-03-05 17:52:59 UTC (rev 124520)
+++ Sandbox/J1m/resumelb/src/zc/resumelb/pool.test 2012-03-05 18:28:29 UTC (rev 124521)
@@ -18,22 +18,22 @@
>>> pool = zc.resumelb.lb.Pool(
... variance=2, backlog_history=2, unskilled_score=.5)
-We specified a number of optional paramters that we'll see in action
+We specified a number of optional parameters that we'll see in action
later:
variance
- How many times the pool mean backlog we'll ket a worker's backlog
+ How many times the pool mean backlog we'll let a worker's backlog
rise before we look for another worker. The default is 4.
backlog_history
- The (aproximate) number of requests to include in the mean backlog
+ The (approximate) number of requests to include in the mean backlog
for a worker. The default is 9.
The pool also has a backlog history, which is the product of the
worker backlog_history and the number of workers.
unskilled_score
- The score to assign to unsklilled workers. The default is 1.
+ The score to assign to unskilled workers. The default is 1.
The get method is used to get a worker from the pool. A request class
@@ -94,12 +94,12 @@
Here, we can see that w1 is used for the foo class and w2 for the bar
class. In the request classes, the worker's score and it's decayed
-backlog is shown in paretheses. We see that both workers have a score
+backlog is shown in parentheses. We see that both workers have a score
of 1.0. This is the default score for new workers. We'll say more
about this later.
The decayed backlog, for the pool, and for workers, is an "average"
-backlog over a backlog history, which is a configation parameter.
+backlog over a backlog history, which is a configuration parameter.
Let's add another worker:
@@ -142,9 +142,9 @@
1: [w2]
8: [w1, w3]
-Something interesting heppened here. After several requests, the
+Something interesting happened here. After several requests, the
pools switched back and forth between w1 and w3. It never switched to
-w2. This is because, as the backlogs for w2 and w2 increased, so did
+w2. This is because, as the backlogs for w1 and w3 increased, so did
the mean backlog. This is useful, because it prevents a single
request class from taking over the entire pool. Let's see what
happens when we add some new workers:
@@ -171,7 +171,7 @@
request, it went to the newest new worker. The subsequent request
went to that worker because it was skilled and had a fairly low backlog.
-When a worker is done doing it's work, we put it back in the pool:
+When a worker is done doing its work, we put it back in the pool:
>>> for i in range(8):
... pool.put(w1)
Modified: Sandbox/J1m/resumelb/src/zc/resumelb/protocol.txt
===================================================================
--- Sandbox/J1m/resumelb/src/zc/resumelb/protocol.txt 2012-03-05 17:52:59 UTC (rev 124520)
+++ Sandbox/J1m/resumelb/src/zc/resumelb/protocol.txt 2012-03-05 18:28:29 UTC (rev 124521)
@@ -1,5 +1,5 @@
LB's and workers communicate via a simple protocol
-===================================================
+==================================================
They send each other sized network messages. The network messages
consist of:
@@ -13,6 +13,6 @@
- environment dict from LB->worker
- string part of HTTP message body
- '' end of HTTP message marker
-- None from lb->worker indicating request cancelation
+- None from lb->worker indicating request cancellation
- (status, headers) worker->lb start response
Modified: Sandbox/J1m/resumelb/src/zc/resumelb/worker.test
===================================================================
--- Sandbox/J1m/resumelb/src/zc/resumelb/worker.test 2012-03-05 17:52:59 UTC (rev 124520)
+++ Sandbox/J1m/resumelb/src/zc/resumelb/worker.test 2012-03-05 18:28:29 UTC (rev 124521)
@@ -11,7 +11,7 @@
... zc.resumelb.tests.app(), ('127.0.0.1', 0), history=5)
Here we created a worker using a test application, telling it
-an address to listen on and to compute it's resume based on roughly
+an address to listen on and to compute its resume based on roughly
five requests.
We could also have specified a max_skill_age parameter, which controls
@@ -35,13 +35,13 @@
marshalled data string. Helper functions help us read and write
messages. When workers accept a connection, they send their resume
and then wait for work to do. Because our worker has no experience
-:), it's resume is empty:
+:), its resume is empty:
>>> from zc.resumelb.util import read_message, write_message
>>> read_message(worker_socket)
(0, {})
-When the worker sends it's resume, it sends 0 as the request number.
+When the worker sends its resume, it sends 0 as the request number.
Now, let's send a request to the worker. Requests are based on wsgi
environments. We'll use webob to help us set this up.
@@ -120,7 +120,7 @@
>>> write_message(worker_socket, 3, newenv('1', '/hi.html'))
>>> write_message(worker_socket, 4, newenv('1', '/hi.html'))
-At this point, we have 3 outstading requests. Let's create 3 bodies:
+At this point, we have 3 outstanding requests. Let's create 3 bodies:
>>> b2 = 'x'*1000
>>> b3 = 'y'*10000
@@ -198,7 +198,7 @@
<BLANKLINE>
hello world
-The next message we recieve will be the new resume:
+The next message we receive will be the new resume:
>>> zero, resume = read_message(worker_socket)
>>> zero, resume.keys(), [x for x in resume.values() if type(x) != float]
@@ -212,7 +212,7 @@
would be less than 10.
We can reuse request numbers. We normally don't reuse request numbers
-until we get to 4 billion or so., But lets make sure we can reuse
+until we get to 4 billion or so., But let's make sure we can reuse
them:
>>> write_message(worker_socket, 1, newenv('', '/gen.html?size=100'), '')
@@ -231,14 +231,14 @@
In a production deployment, there will likely be multiple load
balancers for redundancy. In this case, there are multiple
-connections to workers. Let's excercise that and make sure it works
+connections to workers. Let's excecise that and make sure it works
properly.
Open a second connection:
>>> worker_socket2 = gevent.socket.create_connection(worker.addr)
-We're immediately send the worker's resume.
+We're immediately sent the worker's resume.
>>> read_message(worker_socket2)[0]
0
@@ -373,7 +373,7 @@
--------------------------
Workers can store their resumes. This is useful if a worker has
-state, such as cache data that can be retained accross restarts. A
+state, such as cache data that can be retained across restarts. A
worker will load data from and save data to a file if the
``resume_file`` option is used to specify a resume file name:
@@ -386,7 +386,7 @@
... history=2, max_skill_age=3,
... resume_file='resume.mar')
-Note that we specified a max_skill_age if 4, rather than the default
+Note that we specified a max_skill_age of 4, rather than the default
10x the history.
>>> from pprint import pprint
@@ -421,7 +421,7 @@
>>> print_response(worker_socket, 4) # doctest: +ELLIPSIS
4 200 OK...
-We'll get a new resume that ha sdropped the 'a' and 'b' skills:
+We'll get a new resume that has dropped the 'a' and 'b' skills:
>>> rno, resume = read_message(worker_socket)
>>> rno, sorted(resume)
@@ -430,8 +430,8 @@
Ignore empty strings in application iterables
---------------------------------------------
-The lb/worker protocol uses empty strings as indicate end-of-message
-markers. If an application returns empty strings in it's returned
+The lb/worker protocol uses empty strings to indicate end-of-message
+markers. If an application returns empty strings in its returned
iterable, the worker must ignore them.
>>> env = newenv('test', '/sneaky.html')
@@ -449,7 +449,7 @@
The load balancer can cancel a request at various stages.
-If we send a cancelation after a request has been finalized, the
+If we send a cancellation after a request has been finalized, the
cancellation is ignored:
>>> write_message(worker_socket, 3, None)
@@ -474,18 +474,17 @@
>>> env = newenv('test', '/gsleep.html?dur=.1')
>>> write_message(worker_socket, 6, env, '', None)
-Or requesting tons of data, but before recieving all of it:
+Or requesting tons of data, but before receiving all of it:
>>> env = newenv('test', '/gen.html?size=1000')
>>> write_message(worker_socket, 7, env, '')
>>> gevent.sleep(.01)
>>> write_message(worker_socket, 7, env, None)
-OK, so we sent 3 requests and cancelled all of them. We shouldn't see
-any output for 4 and 5, as they were cancelled completed before they
-were completed. Request 6 will be performed. Some output will be
-probably be written to the socket before the cancellation is seen, but
-not all of it.
+OK, so we sent 3 requests and cancelled all of them. We shouldn't see any
+output for 4 and 5, as they were cancelled before they were completed. Request
+6 will be performed. Some output will be probably be written to the socket
+before the cancellation is seen, but not all of it.
We'll send another request to act as a marker in the output we get
back:
@@ -582,7 +581,7 @@
Also, note that the worker score is based on the time spent in app. It
doesn't include time waiting. We can see this when the worker sends
-us it's resume:
+us its resume:
>>> _ = read_message(worker_socket), read_message(worker_socket)
>>> _, resume = read_message(worker_socket)
Modified: Sandbox/J1m/resumelb/src/zc/resumelb/zk.test
===================================================================
--- Sandbox/J1m/resumelb/src/zc/resumelb/zk.test 2012-03-05 17:52:59 UTC (rev 124520)
+++ Sandbox/J1m/resumelb/src/zc/resumelb/zk.test 2012-03-05 18:28:29 UTC (rev 124521)
@@ -33,7 +33,7 @@
- Registers with ZooKeeper, and
-- Get's settings from ZooKeeper.
+- Gets settings from ZooKeeper.
The server runner takes options:
@@ -41,7 +41,7 @@
A ZooKeeper connection string
path
- A zookeeper where he worker will get settings and publish it's
+ A zookeeper where the worker will get settings and publish its
address.
address
@@ -71,9 +71,9 @@
Normally, when used with paste, the worker function runs forever. We
passed the run argument with a false value. The run argument exists
-soley for testing.
+solely for testing.
-The worker got it's settings from the tree:
+The worker got its settings from the tree:
>>> worker.max_skill_age
90
@@ -84,13 +84,13 @@
>>> worker.decay
0.96875
-It loaded it's resume from resume.mar:
+It loaded its resume from resume.mar:
>>> from pprint import pprint
>>> pprint(worker.resume)
{'a': 1.0, 'b': 2.0}
-It register's it's address as an emphemeral subnode of the provider's
+It registers its address as an ephemeral subnode of the provider's
subnode of the given path:
>>> [waddr] = zk.get_children('/test/lb/workers/providers')
@@ -277,7 +277,7 @@
>>> sock = gevent.socket.create_connection(addr)
>>> sock2 = gevent.socket.create_connection(addr)
- >>> sock3 = gevent.socket.create_connection(addr, .01)
+ >>> sock3 = gevent.socket.create_connection(addr, .00001)
Traceback (most recent call last):
...
timeout: timed out
@@ -329,7 +329,7 @@
the servers, but we didn't close the open worker connections. We
don't have the plumbing to do that and it's only an issue for the tests.
-OK. now let's shut down the server and lb.
+OK. Now let's shut down the server and lb.
>>> server.stop()
>>> lb.stop()
@@ -340,7 +340,7 @@
- The server runs in non-test mode, that
- we can pass an object as the access log parameter (used by
- simulation script.), and that we can pass basoc logging information:
+ simulation script.), and that we can pass basic logging information:
>>> worker_greenlet = gevent.spawn(zc.resumelb.zk.worker,
More information about the checkins
mailing list