Home > Article > Backend Development > A brief analysis of developing large-scale web applications with PHP_PHP tutorial
关于PHP的执行效率,网上的专题文章很多,多是PHP、Java几个阵营的争论;应用的方面不同,执行环境不同,效率的差别会差得比较大。这里所说的“ 大型”应用不是说像Google、eBay、Yahoo这类大型网站的具体实施,只是希望大家的系统可以运行得更快更流畅,可以承载更多的用户在线,希望可以给PHP的初学者一点帮助。 这里所说的“大型”应用不是说像Google、eBay、Yahoo这类大型网站的具体实施,我也没有意图劝说读者放弃自己的概念和信仰,只是希望大家的系统可以运行得更快更流畅,可以承载更多的用户在线,希望可以给PHP的初学者一点帮助。 关于PHP的执行效率,网上的专题文章很多,多以PHP、Java几个阵营的争论开始,以一个不确定的期待结束,很少看见一个明确的结论。确实,程序的执行效率是很难从比较中得出的。应用的方面不同,执行环境不同,效率的差别会差得比较大。而且效率也是需要权衡的,大家都知道汇编语言很底层,可以写出非常高效的程序,但是我还很少,应该说是几乎没看过有人用汇编做Web开发,而且有能力用汇编写出高效程序的人似乎都是值得大家仰视的,哈哈~我们没有必要去讨论PHP和汇编到底差多少,只要知道自己的PHP和别人的PHP差多少就可以了。 首先,先要明确这篇文章的前提:必须有一台或更多的可以被自己操纵的服务器,而不是虚拟主机空间。毕竟可以在虚拟主机上运行的通用系统已经有了很多经典的作品和成熟的框架,效率挖掘已经被前辈们做得非常出色了,它们的很多理念也被现在很多PHP用户继承和发展,越来越多的所谓“框架”也像满天繁星一样,我也不想再去写那个,因为第一我自己的水平也不怎么样,写不出什么新鲜玩意来,写出来也招人笑,第二是写这个的文章太多了,说法也太多了,混乱是造成很多富有激情的未来天才程序员夭折的最大元凶。 在独立服务器上执行的程序和在虚拟主机上可以运行的程序在效率优化方面有着很大差别。您当然可以把一套discuz不加修改地安装在一台甚至一堆独立服务器上,不过,它真的得到最大的性能优化吗,您真的对得起这一堆服务器吗? 独立服务器指的是,使用者对这台机器有完全的控制权,包括安装、删除软件,配置系统参数甚至修改源代码。基于这样一个开放的硬件平台,性能也不仅仅是体现在速度上,还包括安全性、稳定性等。和虚拟主机不同,用户必须自己配置Web服务器参数,安装和配置PHP、数据库,以及安装各种乱七八糟的东西(我喜欢这么说),当然还要对它们负责。 首先提出几个名词:执行时间、模板、数据库封装、Cache、Buffer、Hash、守护进程、crontab。 执行时间,谁都知道,就是一个程序从执行开始到执行结束所用的时间。因为Web是瞬时的、无状态的,所以执行时间是Web程序执行效率的一个指标,它并不适合衡量C/S程序或者后台守护的程序,因为它们很多都是持续运行的。页面执行时间的一个典型例子就是Discuz论坛页面最下方的时间显式,通常 Discuz都是几毫秒到几十毫秒,和所用的平台、数据量和当前系统压力有关。 模板大家再熟悉不过,虽然有很多人只是在用,但是不知道为什么在用。模板在传统上来说是划分逻辑层的一种途径,在MVC上结构里,它把表示层和下层分离,在实际使用中,它方便程序员和界面设计人员分工合作。然而,现在很多场合中,由于模板的不当使用,它非但没有起到促进程序员和界面设计人员分工合作,反倒成为程序员和美工互相仇视的罪魁(我好像在以前的帖子里这样说过),很多人在抱怨他们不得不花很多时间在整理模板上。 数据库封装似乎和Java的关系更大,它对多种数据库系统提供一个统一调用接口,通常是一些封装好的类,这些类有时也完成一些比如SQL检查、过滤等工作。PHPLIB里的DB封装、PEAR DB、Adodb等都很有名,用的人也很多。 Cache and Buffer seem to be the same thing. Cache is called cache and Buffer is called buffering. In the hardware concept, the purpose of Cache is to connect two devices with different speeds, such as registers and memory, CPU and PCI-Bus, IDE bus and hard disk. The original meaning of Buffer is a spring-like buffer, something used to reduce or absorb the shock of impact. Buffer is a data pre-access method that is used to temporarily store data and transmit it at a speed different from the receiving speed. The Buffer update method can be automatically refreshed according to time intervals, while the Cache pays more attention to the "hit rate" and puts a small amount of data that is frequently used in the current time period into a high-speed device for easy reading and writing. In program development, although there are no high-speed or low-speed devices, data sources can have different reading and writing efficiencies. For a small amount of data, text file reading and writing are usually more efficient than database access, and the same text file reading and writing efficiency on tmpfs is better than direct disk IO efficiency. Buffer is more reflected in process communication and queues. In many cases, it is not because the receiver is unable to read faster, but because there is no need to read faster. A daemon process is a program that is continuously executed in the background. It usually plays a role in monitoring, controlling processes, and providing external services. For example, Apache itself can be understood as a daemon process, although it is actually composed of many frequently updated processes (the main process is fixed). Crontab is a UNIX/Linux scheduled program, a bit like Windows' "scheduled tasks". It sets a specific program to be executed after a certain time interval or at a certain point in time. It is usually used to complete automatic updates, clear temporary data and other operations that are performed automatically once in a period of time. Another special concept (especially for people who are used to general system development) is that after we have an independent server, there is no need to limit ourselves to what PHP can provide. Within the scope of functions, when we unknowingly become the masters of the system, we must work hard to discover this, we have a lot of things at our disposal. PHP is not omnipotent (this is for sure), and its functional shortcomings can be completely compensated by Perl. As a general language, Perl can provide more functional options, and its modules are as dense as grit. The casual and perverted language provides endless energy. For PHP's performance deficiencies, C can be used to make up for it. The foundation of PHP is inherited from C. PHP itself is also developed by C. It is completely reasonable to use C to extend PHP. Linux itself is supported by C and Perl (I say this not to exaggerate the status of Perl. You can take a look at how many Perl scripts there are in a standard Linux. Will the system feel like a disability after leaving Perl? people). PHP inherited most of its syntax from C, and learned most of the Web features, functions, and the "$" symbol that seems to be contradictory to open source (PHP was a Perl script in its early days) from Perl. Let’s analyze some of the code I’m using (Note: Applicable to Linux standalone servers. I seem to have given up on large-scale development for Windows and virtual hosts for a long time). It uses some methods that may be familiar, unfamiliar, or abnormal. My system is RedHat AS3, nothing special, the PHP version is 4.4.0, MySQL is 4.1. I never intentionally write code that must use the new features of PHP5 unless it is really necessary. My Web root directory is under /www. Apache and PHP are installed under /usr/local/ by default. MySQL is a downloaded and compiled binary version, and I also leave it there. Because it's just for testing, I don't want it to look messy. As for actual projects, especially in the case of multiple servers, you need to deploy your system well. In order to make the system structure clearer, I put all the files I need to use in the secondary directory. The following are some fragments of the common header file /includes/kernel/common.inc.php: ﹤?php ﹤?php
if (!defined(IN_BSG)) {
exit;
}
?﹥
The above code ensures that it can only be called by legal programs and will not be included by other files. If the executing program does not define an IN_BSG constant, it will terminate after including the common.inc.php.
list($usec, $sec) = explode(" ", microtime());
$page_time_start = $usec + $sec;
?﹥
You may be familiar with these two lines, which are used to calculate the start execution time of the program. Before the program ends, this will be calculated again in order to find out the time it took to execute the program. If you don't care about this, you can safely comment it out.