DOC: fix a few spelling mistakes

diff --git a/doc/architecture.txt b/doc/architecture.txt
index 6135f80015ad1857f9ba411d54868a799e7f763a..12dda8da73853ed25e15f8ecbdad96621c4a4bd2 100644 (file)
--- a/doc/architecture.txt
+++ b/doc/architecture.txt
@@ -1307,7 +1307,7 @@ persistent connections per user).
 
 Even if you disable keep-alive, if the server takes a long time to respond,
 you still have a high risk of multiple users clicking at the same time and
-having their requests unserved because of server saturation. To workaround
+having their requests unserved because of server saturation. To walk around
 the problem, you increase the concurrent connection limit on the servers,
 but their performance stalls under higher loads.
 

diff --git a/doc/management.txt b/doc/management.txt
index e770b794c27e119b3d2e7c7ef2e7a981fb30a29f..466f40e7b63cdbb26a7b75eaf796844b680e9de1 100644 (file)
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -755,7 +755,7 @@ one first layer running on multiple processes and in charge for the heavy
 processing, passing the traffic to a second layer running in a single process.
 This mechanism is suited to SSL and compression which are the two CPU-heavy
 features. Instances can easily be chained over UNIX sockets (which are cheaper
-than TCP sockets and which do not waste ports), adn the proxy protocol which is
+than TCP sockets and which do not waste ports), and the proxy protocol which is
 useful to pass client information to the next stage. When doing so, it is
 generally a good idea to bind all the single-process tasks to process number 1
 and extra tasks to next processes, as this will make it easier to generate