並發測試開端
前言：
並發模型你們會想到什麽來操作呢，是不是很高大上這個詞語
我們測試常見跟開發人員接口或者並發問題，對我們測試很苦腦有沒有？
記得我剛進測試的時候也是小白一個，做功能一直點點點，然後開發人員說測試一下壓力測試
然後大家就是用工具來進行測試，這樣的方法是可能進行測試，如果開發人員就給了你一個鏈接，什麽都沒有給，你們會在心理說，這怎麽能做並發呢，沒有參數這是我們測試腦袋中第一時間說的話，但很多公司就是這樣，就告訴你在那裏自己做，我們就要寫異步腳本，對性能工具少一點依賴，我們用的最多聽得最多就是Jmeter，SoupUI,LoadRunner等等
現在就給大家舉個例子：
最簡單的並發線程
import socket
response = ‘HTTP/1.1 200 OK\r\nConnection: Close\r\nContent-Length: 11\r\n\r\nHello World‘
server = socket.socket()
server.bind((‘x.x.x.x‘, xxxx))
server.listen(1024)
while True:
client, clientaddr = server.accept()
request = client.recv(1024)
client.send(response)
client.close()
訪問localhost:xxxx，返回“Hello World”
如果你用ab進行測試性能數據
ab -n 10000 -c X http://localhost:xxxx/
Time taken for tests: 2.1234 seconds
發送1萬個請求，X（我的CPU核數為X）個請求同時並發，耗時2.1234秒。
性能瓶頸在哪裏呢？就在上面的兩個半阻塞。
accept和recv是完全阻塞的，而為什麽send是半個阻塞呢？
在內核的 socket實現中，會有兩個緩存 (buffer)。read buffer 和 write buffer 。當內核接收到網卡傳來的客戶端數據後，把數據復制到 read buffer ，這個時候 recv阻塞的進程就可以被喚醒。
當調用 send的時候，內核只是把 send的數據復制到 write buffer 裏，然後立即返回。只有 write buffer 的空間不夠時 send才會被阻塞，需要等待網卡發送數據騰空 write buffer 。在 write buffer的空間足夠放下 send的數據時進程才可以被喚醒。
如果一個請求處理地很慢，其他請求只能排隊，那麽並發量肯定會受到影響。
後面多講一下理論課，並發要知道那些才能進行測試
1.線程
2.進程
3.遠程分布式主機
4.偽線程
。。。。。。。。。。
並發測試開端