实践/实验

1.应用场景

验证确认一些结论,帮助更加深入学习。

2.学习/操作

环境:

windows 10 64位 专业版

php 7.3.4

apache 2.4.39

cpu:i5-6500 3.20GHz  3.19GHz

内存:8G

硬盘:SSD 256GB

 

 

1.利用php产生一千万个一亿的数字字符串形式, 确认占用的存储空间大小.   20191211 周三

<?php
echo microtime().PHP_EOL;
$text_content = '';
$unit_content = '100000000'; //9位
$file_path = './test.txt';
if(!file_exists($file_path)){
    exit('file not exists!');
}

$start_time = time();
$myfile = fopen($file_path, "a") or die("Unable to open file!");
for($i = 0; $i < 10000000; $i++){
    $text_content = $unit_content.',';
    fwrite($myfile, $text_content);
}
fclose($myfile);
$end_time = time();
echo ($end_time - $start_time);
echo microtime();
exit('写入文件成功');

 

 

运行结果:

出现报错,提示服务器出现故障[应是超出php最大执行时间60s]. cpu百分比上升20%左右,内存几乎变化. //备注,这种方式只能作为参考,因为电脑上运行有其他程序

拓展:可分析时空复杂度 TBD

test.txt文件大小:

实践/实验

实践/实验

 

实验调整:

①生成十万个一亿的数字字符串

结果如下:

实验前:

实践/实验

实践/实验

实验中/后:

实践/实验

实践/实验

cpu和内存百分比无明显变化。//很快没有记录下来

执行时间:1.19972700s

 

②百万条

实验前:

实践/实验

实验中/后

实践/实验

实践/实验

实践/实验

执行时间:约12s

文件生成大小为:9.53 MB (10,000,000 字节)

占用空间:9.53 MB (10,002,432 字节)  //占用空间自然是要文件本身大小要大,因为有额外数据存储

 

由上可知:

100万个一亿数字即一千万字节.9.53MB (约为10MB)

则一百亿个一亿数字即占空间95300MB 约为 93GB. 都放在内存,怕是放不下.

要处理这么多数据,只能切割拆分处理。

 

 

实验优化代码:

<?php
$start = array_sum(explode(' ', microtime()));
$text_content = '';
$unit_content = '100000000';
$file_path = './test.txt';
if(!file_exists($file_path)){
    exit('file not exists!');
}

$start_time = time();
$myfile = fopen($file_path, "a") or die("Unable to open file!");
for($i = 0; $i < 1000; $i++){
    $text_content = $unit_content.',';
    fwrite($myfile, $text_content);
}
//记得关闭流
fclose($myfile);
$end = array_sum(explode(' ', microtime()));
$interval = $end - $start;
echo $interval;
exit('写入文件成功');

 

 

 

2.客户端传递参数的大小有限制吗?

资料显示:get请求有限制[具体值跟浏览器种类有关]通常为2048字节左右,post理论上没有限制,但实际上跟服务器硬件[内存]有关.

GET: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/GET

POST: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/POST

参见: https://www.cnblogs.com/elian91/p/11125201.html //关于get请求的长度限制到底是多少?----一个误区,一个教训

 

验证:TBD

IE 11.476  最大为: 2024+参数名name+'=' =2049 字节

实践/实验

Chrome 版本 78.0.3904.108(正式版本) (64 位)最大为: 8171+test+'=' = 8176 字节  长度限制的是插叙字符串的长度.

实践/实验

 

可以参考:

关于get请求的长度限制到底是多少?----一个误区,一个教训

截至今日之前,我一直因为从某处看到get、post区别中写的:get有长度限制,1024B。很抱歉在未经过个人的检验后,直接奉为正确的定义(也提醒我个人:以后概念理论,还是需要好好验证或求证,要能在繁杂的网络知识中,认真求真,以防以讹传讹!!!)。

       今日,看到前同事大牛多年前的****知识总结,发现原来一直信奉的1024Get请求长度,是错误的。下面把从权威官网的解释复制过来,以做更正。

       1、Http get方法提交的数据大小长度并没有限制,Http协议规范没有对URL长度进行限制。

            目前说的get长度有限制,是特定的浏览器及服务器对它的限制。

        各种浏览器和服务器的最大处理能力如下:

        IE:对URL的最大限制为2083个字符,若超出这个数字,提交按钮没有任何反应。

        Firefox:对Firefox浏览器URL的长度限制为:65536个字符。

        Safari:URL最大长度限制为80000个字符。

        Opera:URL最大长度限制为190000个字符。

        Google(chrome):URL最大长度限制为8182个字符。

        Apache(Server):能接受的最大url长度为8192个字符(这个准确度待定???)

        Microsoft Internet Information Server(IIS):n能接受最大url的长度为16384个字符。

        2、理论上讲,post是没有大小限制的。Http协议规范也没有进行大小限制,起限制作用的是服务器处理程序的处理能力。

        Tomcat下默认post长度为2M,可通过修改conf/server.xml中的“maxPostSize=0”来取消对post大小的限制。

 

 

注意:(若长度超限,则服务端返回414标识)

1、首先即使有长度限制,也是限制的是整个URI长度,而不仅仅是你的参数值数据长度。

2、HTTP协议从未规定GET/POST的请求长度限制是多少

3、所谓的请求长度限制是由浏览器和web服务器决定和设置的,浏览器和web服务器的设定均不一样,

     这依赖于各个浏览器厂家的规定或者可以根据web服务器的处理能力来设定。

 

GET VS POST扩展:

1、多数浏览器对于POST采用两阶段发送数据的,先发送请求头,再发送请求体,即使参数再少再短,也会被分成两个步骤来发送(相对于GET),也就是第一步发送header数据,第二部再发送body部分。Http是应用层的协议,而再传输层有些情况TCP会出现两次连结的过程,http协议本身不保存状态信息,一次请求一次响应。对于TCP而言,通信次数越多反而可靠性越低,能在一次连结中传输完需要的信息是最可靠的,所以尽量使用GET请求来减少网络耗时。如果通信时间增加,这段时间客户端于服务器端一直保持连接状态,在服务器侧负载可能会增加,可靠性会下降。

2、GET请求能够被cache,GET请求能够被保存在浏览器的浏览历史里面(密码等重要数据GET提交,别人查看历史记录,就可以直接看到这些私密数据)POST不进行缓存。

3、GET参数是带在URL后面,传统IE中URL的最大可用长度为2048字符,其他浏览器对URL长度限制实现上有所不同。POST请求无长度限制(目前理论上是这样)。

4、GET提交的数据大小,不同浏览器的限制不同,一般在2k-8k之间,POST提交数据比较大,大小靠服务器的设定值限制,而且某些数据只能用POST方法【携带】,比如file。

5、全部用POST不是十分合理,最好先把请求按功能和场景分下类,对数据请求频繁,数据不敏感且数据量在普通浏览器最小限定的2k范围内,这种情况使用GET。其他地方使用POST。

6、GET的本质是【得】,而POST的本质是【给】。而且,GET是【幂等】的,在这一点上,GET被认为是【安全的】。实际上server端也可以用作资源更新,但是这种用法违反了约定,容易造成CSRF(跨站请求伪造)。

参考文档:

http://blog.sina.com.cn/s/blog_13a2fc60f0102yymc.html

 

后续补充
...

3.问题

TBD

4.参考

TBD

后续补充

...