Maison >développement back-end >tutoriel php >PHP 是读取数据库在模版遍历快还是 从文件读取html快?

PHP 是读取数据库在模版遍历快还是 从文件读取html快?

WBOY
WBOYoriginal
2016-09-28 08:54:091257parcourir

之前在做一个商城网站,有一个模块是定制首页,时间赶直接提取页面html内容用php写进文件里,首页读取的时候,再读取那个文件输出给模版。题目的读取数据库指读取定制数据,不是html内容。

现在不赶时间了,想知道:

  1. 如果在多人访问并发高的情况下,是读取文件快?还是从数据库读取数据快?

  2. 如果写入文件内容多,文件比较大的情况是不是读取时间慢?

  3. 我用的TP框架,直接在模版里会不会更好

  4. 再问一下,想测试并发要怎么测试?要搜哪些关键词?

ps:刚出来工作的小白,求回答指教

回复内容:

之前在做一个商城网站,有一个模块是定制首页,时间赶直接提取页面html内容用php写进文件里,首页读取的时候,再读取那个文件输出给模版。题目的读取数据库指读取定制数据,不是html内容。

现在不赶时间了,想知道:

  1. 如果在多人访问并发高的情况下,是读取文件快?还是从数据库读取数据快?

  2. 如果写入文件内容多,文件比较大的情况是不是读取时间慢?

  3. 我用的TP框架,直接在模版里会不会更好

  4. 再问一下,想测试并发要怎么测试?要搜哪些关键词?

ps:刚出来工作的小白,求回答指教

  1. 数据库的数据也是存在文件里的,不考虑数据库做内存缓存的情况,单纯读文件当然要比读数据库快,因为数据库还要经过查询过程以及其他处理流程。但是,如果文件数量过多时,还需要考虑文件系统的查询速度,这个速度在文件过多时是慢于数据库查询的。

  2. 文件读取时间自然取决于文件的大小,但是如果文件中所有的内容都是你想要的,这个时间自然是不可缺少的。如果你只想读取部分的文件内容,可以通过seek来移动文件指针。

  3. TP框架的模板是进过编译的,也就是说,实际执行时不会使用你写的模板文件,而是使用编译后的模板,所以你大可放心的使用include,不必在意性能的问题。

  4. 并发测试准确来说应该叫压力测试,搜索压力测试方案即可。

针对你的问题,

  1. 高并发的情况下,直接数据库肯定会很慢,至少在数据库上有一个Cache层,Cache层效率:

    <code>文件 </code>

    看你的需求貌似还有生成静态文件的步骤,这里提供你几个关键词:

    • ob_start

    • 伪静态

    • CDN

  2. 如果写入的文件内容多,这个没办法,我们一般会使用Cache等来做整体架构方案,而非单纯写入这么简单

    如果读取的文件(特指PHP文件)比较大,考虑开启OpCache加强速度

  3. 你这是include一个模板文件,也就是PHP执行的include,效率等同PHP的include
    如果访问的页面全部静态文件,需要嵌入子模板的情况,SSI(ApachenginX)会比PHP的include快很多

    所以,你问题的答案:HTML 是最快的,都无需执行PHP,但是需要提前生成好

  4. 并发测试,从关键词apache benchmark开始,接下来你会搜到很多你想要的内容。

首先,它们速度区别不大,文件快点,但是如果都放数据库好管理一些。

其次呢,谁快不重要,这些CMS类型的网站,可以通过静态化来进行优化,静态化后和页面生成时间就无关了。

首先, 内存 >> 文件
其次, 数据库也是把数据存放在文件的(当然,数据库有查询缓存)
非关系型的数据, 当然是存文件快
但同个文件夹下不可存放大量文件(寻址慢),可使用文件名目录分割, 如:
文件名 dsaferdfsasxfsfsdf.dat
取前两字符创建一级目录, 存放为
ds/dsaferdfsasxfsfsdf.dat
lokljljoiomlkml.dat >> lo/lokljljoiomlkml.dat

TP自带简易缓存方法S(), 默认为文件驱动, 如果缓存驱动用Memcahced或Redis的话, 应该会比文件快, 前提是Memached或Redis服务器在本机上, 或在千兆以上的局域网内

并发测试的话, Linux和Darwin(OS X)内核系统可以用ab 命令(ApacheBench), 如:
ab -k -n 1000 -c 100 "http://www.baidu.com"
// 发起1000个请求, 每次并发100(该值有会有上限, 视系统设置, 一般默认为256)

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn