jQuery怎么解析Json字符串

一、jQuery解析Json数据格式： 
使用这种方法，必须在Ajax请求中设置参数: 
1、dataType: "json" 
获取通过回调函数返回的数据并解析得到我们想要的值，看源码：

jQueryajax({ 
    url: full_url, 
    dataType: "json", 
    success: function(results) { 
        alert(resultname); 
    } 
});

jquery异步请求将type（一般为这个配置属性）设为“json”，或者利用$getJSON()方法获得服务器返回，那么就不 需要eval（）方法了，因为这时候得到的结果已经是json对象了，只需直接调用该对象即可，这里以$getJSON方法为 例：

var data=" 
{ 
    root: 
    [ 
        {name:'1',value:'0'}, 
        {name:'6101',value:'北京市'}, 
        {name:'6102',value:'天津市'}, 
        {name:'6103',value:'上海市'}, 
        {name:'6104',value:'重庆市'}, 
        {name:'6105',value:'渭南市'}, 
        {name:'6106',value:'延安市'}, 
        {name:'6107',value:'汉中市'}, 
        {name:'6108',value:'榆林市'}, 
        {name:'6109',value:'安康市'}, 
        {name:'6110',value:'商洛市'} 
    ] 
}";
$getJSON(">});

二、jQuery解析Json对象： 
jQuery提供了另一种方法“parseJSON”，这需要一个标准的JSON字符串，并返回生成的JavaScript对象。语法： 
data = $parseJSON(string); 
看看它是如何运用的到实际开发中的：

jQueryajax({ 
    url: dataURL, success: function(results) { 
        var parsedJson = jQueryparseJSON(results); 
        alert(parsedJsonname); 
    } 
});

作为高性能WEB服务器，只调整Nginx本身的参数是不行的，因为Nginx服务依赖于高性能的 *** 作系统。

以下为常见的几个Linux内核参数优化方法。

netipv4tcp_max_tw_buckets

对于tcp连接，服务端和客户端通信完后状态变为timewait，假如某台服务器非常忙，连接数特别多的话，那么这个timewait数量就会越来越大。
毕竟它也是会占用一定的资源，所以应该有一个最大值，当超过这个值，系统就会删除最早的连接，这样始终保持在一个数量级。
这个数值就是由netipv4tcp_max_tw_buckets这个参数来决定的。
CentOS7系统，你可以使用sysctl -a |grep tw_buckets来查看它的值，默认为32768，
你可以适当把它调低，比如调整到8000，毕竟这个状态的连接太多也是会消耗资源的。
但你不要把它调到几十、几百这样，因为这种状态的tcp连接也是有用的，
如果同样的客户端再次和服务端通信，就不用再次建立新的连接了，用这个旧的通道，省时省力。

netipv4tcp_tw_recycle = 1

该参数的作用是快速回收timewait状态的连接。上面虽然提到系统会自动删除掉timewait状态的连接，但如果把这样的连接重新利用起来岂不是更好。
所以该参数设置为1就可以让timewait状态的连接快速回收，它需要和下面的参数配合一起使用。

netipv4tcp_tw_reuse = 1

该参数设置为1，将timewait状态的连接重新用于新的TCP连接，要结合上面的参数一起使用。

netipv4tcp_syncookies = 1

tcp三次握手中，客户端向服务端发起syn请求，服务端收到后，也会向客户端发起syn请求同时连带ack确认，
假如客户端发送请求后直接断开和服务端的连接，不接收服务端发起的这个请求，服务端会重试多次，
这个重试的过程会持续一段时间（通常高于30s），当这种状态的连接数量非常大时，服务器会消耗很大的资源，从而造成瘫痪，
正常的连接进不来，这种恶意的半连接行为其实叫做syn flood攻击。
设置为1，是开启SYN Cookies，开启后可以避免发生上述的syn flood攻击。
开启该参数后，服务端接收客户端的ack后，再向客户端发送ack+syn之前会要求client在短时间内回应一个序号，
如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法，于是不会发ack+syn给客户端，更涉及不到重试。

netipv4tcp_max_syn_backlog

该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包，服务端收到后，会记录一下，
该参数决定最多能记录几个这样的连接。在CentOS7，默认是256，当有syn flood攻击时，这个数值太小则很容易导致服务器瘫痪，
实际上此时服务器并没有消耗太多资源（cpu、内存等），所以可以适当调大它，比如调整到30000。

netipv4tcp_syn_retries

该参数适用于客户端，它定义发起syn的最大重试次数，默认为6，建议改为2。

netipv4tcp_synack_retries

该参数适用于服务端，它定义发起syn+ack的最大重试次数，默认为5，建议改为2，可以适当预防syn flood攻击。

netipv4ip_local_port_range

该参数定义端口范围，系统默认保留端口为1024及以下，以上部分为自定义端口。这个参数适用于客户端，
当客户端和服务端建立连接时，比如说访问服务端的80端口，客户端随机开启了一个端口和服务端发起连接，
这个参数定义随机端口的范围。默认为32768 61000，建议调整为1025 61000。

netipv4tcp_fin_timeout

tcp连接的状态中，客户端上有一个是FIN-WAIT-2状态，它是状态变迁为timewait前一个状态。
该参数定义不属于任何进程的该连接状态的超时时间，默认值为60，建议调整为6。

netipv4tcp_keepalive_time

tcp连接状态里，有一个是established状态，只有在这个状态下，客户端和服务端才能通信。正常情况下，当通信完毕，
客户端或服务端会告诉对方要关闭连接，此时状态就会变为timewait，如果客户端没有告诉服务端，
并且服务端也没有告诉客户端关闭的话（例如，客户端那边断网了），此时需要该参数来判定。
比如客户端已经断网了，但服务端上本次连接的状态依然是established，服务端为了确认客户端是否断网，
就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒，建议设置为30秒。

netipv4tcp_keepalive_intvl

该参数和上面的参数是一起的，服务端在规定时间内发起了探测，查看客户端是否在线，如果客户端并没有确认，
此时服务端还不能认定为对方不在线，而是要尝试多次。该参数定义重新发送探测的时间，即第一次发现对方有问题后，过多久再次发起探测。
默认值为75秒，可以改为3秒。

netipv4tcp_keepalive_probes

第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测，但并没有定义一共探测几次才算结束。
该参数定义发起探测的包的数量。默认为9，建议设置2。
设置和范例
在Linux下调整内核参数，可以直接编辑配置文件/etc/sysctlconf，然后执行sysctl -p命令生效。

WebSocket是一种在单个TCP连接上进行全双工通信的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455，并由RFC7936补充规范。WebSocket API也被W3C定为标准。

WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

服务端：

客户端：

启动ws服务端

启动ws客户端，发送和接收效果：

ws服务端，接收和发送效果：

tesserocr是Python的一个OCR识别库，但其实是对tesseract做的一层Python API封装，所以它的核心是tesseract，因此安装tesserocr之前，需要先安装tesseract
这里我安装的是 tesseract-ocr-setup-30502-20180621exe
安装的语言包的时候，耐心等待，会很久。
验证安装
安装成功之后验证：
在命令行下输入：tesseract imagepng stdout -l eng
Tesseract配置环境变量
配置TESSDATA_PREFIX：
添加至Path变量：
复制tessdata整个文件夹至Python安装目录中：
安装Tesserocr
遇到的很坑的就是在安装Tesserocr的时候，pip3 install pillow命令并没有那么顺利
问题一：pip3 install pillow错误如下：
先不要着急去安装Microdoft Visual C++ 140，我们换一种安装方式
首先下载对应的whl文件，一定要与tesseract版本配对：
运行命令：pip3 install tesserocr-222-cp36-cp36m-win_amd64whl
问题来了，并不能安装成功，反而提示：tesserocr-222-cp36-cp36m-win_amd64whl is not a supported wheel on this platform
解决如下：查看pip支持的文件名还有版本
$ import pip
$ import pip_internal
$ print(pip_internalpep425tagsget_supported())
但是tesserocr暂时没有看到cp37的版本whl文件，由于我目前本地是python370
所以最终，我选择将python版本往下降，重新安装了python366
然后再次运行：pip3 install tesserocr-222-cp36-cp36m-win_amd64whl
验证安装
文章最后发布于: 2018-09-14
版权声明：本文为博主原创文章，遵循 CC 40 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：>Sanic:

Fiber:

压测使用的程序是 go-stress-testing ， 1000 个并发，每个并发进行 1000 次请求。

每栏对应的字段为：

Sanic:

Fiber:

可以看出来， sanic 和 fiber 差别不大， sanic 的性能几乎与 fiber 持平，可能是当下最高性能的 Python Web 框架，没有之一，即便是之前较为突出的异步框架 fastapi 也要落后于 sanic 。

附上 fastapi 的结果：

Flask 、 Django 等框架不在本文讨论范围之内，这二者本就不是为了高性能设计的框架，没有对比的意义。

sanic 还有一个优势，就是其没有开发服务器，用 sanic -w 8 mainapp 运行的服务器就是生产服务器。

如果有想用 Python 开发 Web 服务器的，建议优先考虑 sanic ，但 fastapi 其实也够用了。

---