亲宝软件园·资讯

展开

LAMP应用程序 调整优化您的LAMP应用程序的5种简单方法

人气:0
想了解调整优化您的LAMP应用程序的5种简单方法的相关内容吗，在本文为您仔细讲解LAMP应用程序的相关知识和一些Code实例，欢迎阅读和指正，我们先划重点：LAMP,应用程序，下面大家一起来学习吧。

简介

Wikipedia、Facebook 和 Yahoo! 等主要 web 属性使用 LAMP 架构来为每天数百万的请求提供服务，而 Wordpress、Joomla、Drupal 和 SugarCRM 等 web 应用程序软件使用其架构来让组织轻松部署基于 web 的应用程序。

该架构的优势在于其简单性。而 .NET 这样的堆栈和 Java™ 技术可能使用大量硬件、昂贵的软件栈和复杂的性能调优，LAMP 堆栈可以运行于商品硬件之上，使用开源软件栈。由于软件栈是一个松散的组件集，而非一个整体堆栈，性能调优是一大挑战，因为需要分析和调优每个组件。

然而，这有几个个简单性能任务会对任何规模的网站的性能产生巨大的影响。在本文中，我们将探讨旨在优化 LAMP 应用程序性能的 5 个这样的任务。这些项目应当很少需要对您的应用程序进行架构更改，使其成为最大化您的 web 应用程序所需的响应能力和硬件需求的安全、便捷的选择。

使用操作码缓存

提高任何 PHP 应用程序（当然是 LAMP 中的 “P”）的性能的最简单方式是利用一个操作码缓存。对于我使用的任何网站，它是我确保存在的一项内容，因为性能影响很大（很多时候有了操作码缓存，响应时间可减少一半）。但是对 PHP 不熟悉的大部分人的一个很大的疑问是，为何改进会如此之大。答案在于 PHP 如何处理 web 请求。图 1 概览了 PHP 请求的流程。


图 1. PHP 请求
图表展示 PHP 请求的流程，从 PHP 脚本到解析到最后的输出 

由于 PHP 是一种解释语言，而非 C 或 Java 等编译语言，对每个请求执行了 “解析-编译-执行” 的整个步骤。您可以看到为何这会耗时、耗资源，特别是当脚本在请求之间很少变化时。解析和编译脚本之后，脚本作为一系列操作码处于机器可解析状态。这是操作码缓存发挥效用的地方。它作为一系列操作码缓存这些编译脚本，以避免为解析和编译每个请求步骤。您将在图 2 中看到这样的工作流是如何运作的。

图 2. PHP 请求使用操作码缓存
流程图展示逻辑流如何检查缓存的操作码并跳过解析和编译步骤（如果有的话） 

因此当 PHP 脚本的缓存操作码存在时，我们可以跳过 PHP 请求流程的解析和编译步骤，直接执行缓存操作码并输出结果。检查算法负责处理您可能对脚本文件进行了更改的情况，因此在已变更脚本的第一个请求后，会为随后的请求自动重新编译和缓存操作码，替换缓存的脚本。

操作码缓存对于 PHP 流行已久，其中早期的一些要追溯到 PHP V4 的全盛期。目前有一些流行选项正在积极开发和使用中：

毫无疑问，一个操作码缓存是通过在每次请求后消除解析和编译脚本的需要来加速 PHP 的第一步。完成第一步之后，您应当看到响应时间和服务器负载方面的改进。但是优化 PHP 可以做的不止这些，我们接下来将加以讨论。

优化您的 PHP 设置

虽然实现操作码缓存是性能改进的一大创举，不过也有大量其他优化选项可供您基于 php.ini 文件中的设置优化您的 PHP 设置。这些设置更适合于生产实例；在开发或测试实例上，您可能不希望做这些变更，因为它会使得应用程序问题的调试变得更难。

让我们看一下对于性能提升很重要的一些项目。

应当禁用的选项

有若干 php.ini 设置应当予以禁用，因为它们常用作向后兼容性：

然而，在遗留代码上禁用这些选项会有风险，因为它们可能取决于其设置来实现正确执行。不应当基于被设置的这些选项来开发任何新代码，而且可能的话，您应当寻求方法来重构您的现有代码，避免使用它们。

应当禁用或调整设置的选项

您可以启用 php.ini 文件的一些优秀性能选项，来提升您的脚本速度：

就以应当在您的生产实例上配置的设置而言，这些被看作是 “唾手可得”。就 PHP 而言，还有一件事需要考虑。这就是您的应用程序中 require() 和 include()（以及其同级 require_once() 和 include_once()）的使用。这些函数优化您的 PHP 配置和代码，以防止对每个请求进行不必要的文件状态检查，从而减少响应时间。

管理您的 require() 和 include()

从性能来看，文件状态调用（即为检查一个文件是否存在而对底层文件系统进行的调用）相当昂贵。文件状态的最大元凶之一以 require() 和 include() 语句的形式出现，这两个语句用于将代码带到脚本中。require_once() 和 include_once() 的同级调用更成问题，因为它们不仅需要验证文件是否存在，而且它之前没有包含在内。

那么解决这个问题的最好方式是什么？您可以做一些事来加快解决。

APC 和 Wincache 还有用于缓存 PHP 进行的文件状态检查结果的机制，因此无需进行反复的文件系统检查。当您将 include 文件名保留为静态而非变量驱动的时，它们最有效，因此尽可能尝试这样做很有用。

优化您的数据库

数据库优化很快会成为一个前沿话题，我几乎没有空间在这里完全公正地做这个话题。但是如果您在寻求优化您的数据库的速度，首先应当采取一些步骤，这应当对常见问题有所帮助。

将数据库放在自己的机器上

数据库查询自身可以变得相当激烈，通常在对大小合理的数据集执行简单的 SELECT 语句时限定在 100% 的 CPU。如果您的 web 服务器和数据库服务器都在竟用单一机器上的 CPU 时间，这无疑将减慢您的请求速度。因此我想第一步最好是将 web 服务器和数据库服务器放在单独的机器上，确保您的数据库服务器是两者中更强健的（数据库服务器喜欢大量内存和多个 CPU）。

合理设计和编制表索引

数据库性能的最大问题可能源自于不良数据库设计和缺失索引。SELECT 语句通常是运行在典型 web 应用程序中的最常见的查询类型。它们也是在数据库服务器上运行的最耗时的查询。此外，这些类型的 SQL 语句对适当的索引和数据库设计最敏感，因此查看以下指示，获取实现最优性能的技巧。

分析在服务器上运行的查询

改进数据库性能的最佳方法是分析在您的数据库服务器上运行什么查询，且运行它们需要多长时间。几乎每个数据库都有具有这种功能的工具。对于 MySQL，您可以利用慢查询日志来查找有问题的查询。要使用它，在 MySQL 配置文件中将 slow_query_log 设置为 1，然后将 log_output 设置为 FILE，将它们记录到文件 hostname-slow.log 中。您可以设置 long_query_time 阈值，确定查询必须运行多少秒才被看作是 “慢查询”。我想建议将该阈值首先设置为 5 秒，随着时间的推移将其缩减为 1 秒，具体取决于您的数据集。如果您探究该文件，您会看到类似于清单 1 的详细查询。


清单 1. MySQL 慢查询日志

				
/usr/local/mysql/bin/mysqld, Version: 5.1.49-log, started with:
Tcp port: 3306 Unix socket: /tmp/mysql.sock
Time         Id Command  Argument
# Time: 030207 15:03:33
# User@Host: user[user] @ localhost.localdomain [127.0.0.1]
# Query_time: 13 Lock_time: 0 Rows_sent: 117 Rows_examined: 234
use sugarcrm;
select * from accounts inner join leads on accounts.id = leads.account_id;

我们想要考虑的关键对象是 Query_time，显示查询需要的时间。另一项要考虑的是 Rows_sent 和 Rows_examined 的数量，因为这些可指这样的情况：其中如果一个查询察看太多行或返回太多行，就会被错误地书写。您可以更深入地钻研如何写查询，即在查询开始处加上 EXPLAIN，它会返回查询计划，而非结果集，如清单 2 所示。


清单 2. MySQL EXPLAIN 结果

				
mysql> explain select * from accounts inner join leads on accounts.id = leads.account_id;
+----+-------------+----------+--------+--------------------------+---------+---
| id | select_type | table  | type  | possible_keys      
 | key   | key_len | ref            | rows | Extra |
+----+-------------+----------+--------+--------------------------+---------+--------
| 1 | SIMPLE   | leads  | ALL  | idx_leads_acct_del    | NULL  | NULL  
| NULL           | 200 |    |
| 1 | SIMPLE   | accounts | eq_ref | PRIMARY,idx_accnt_id_del | PRIMARY | 108  
| sugarcrm.leads.account_id |  1 |    |
+----+-------------+----------+--------+--------------------------+---------+---------
2 rows in set (0.00 sec)

MySQL 手册更深入探究 EXPLAIN 输出的主题（参见 参考资料），但是我考虑的一项重要内容是 ‘type' 列为 ‘ALL' 的地方，因为这需要 MySQL 做一个全表扫描，且不需要键来执行查询。这些帮助您在添加索引时会大幅提高查询速度。

有效缓存数据

正如我们在上一节看到的，数据库往往容易成为您 web 应用程序性能的最大痛点。但是如果您要查询的数据不经常改变怎么办？在这种情况下，一个好的选择就是在本地存储这些结果，而非针对每个请求调用查询。

我们之前探究的两个操作码缓存 APC 和 Wincache 具有实现上述操作的工具，其中您可以将 PHP 数据直接存储到一个共享内存段中，便于快速查询。清单 3 提供了具体示例。


清单 3. 使用 APC 缓存数据库结果的示例

				
<?php

function getListOfUsers()
{
  $list = apc_fetch('getListOfUsers');
  
  if ( empty($list) ) {
    $conn = new PDO('mysql:dbname=testdb;host=127.0.0.1', 'dbuser', 'dbpass');
    $sql = 'SELECT id, name FROM users ORDER BY name';
    foreach ($conn->query($sql) as $row) {
      $list[] = $row;
    }
    
    apc_store('getListOfUsers',$list);
  }
  
  return $list;
}

我们仅需一次执行查询。之后，我们将结果推送到 getListOfUsers 键下的 APC 缓存中。从这里开始，直到缓存到期，您就能够直接从缓存中获取结果数组，跳过 SQL 查询。

APC 和 Wincache 并非一个用户缓存的惟一选择；memcache 和 Redis 是不需要您在与 Web 服务器相同的服务器上运行用户缓存的其他流行选择。这就提高了性能和灵活性，特别是当您的 web 应用程序跨多个 Web 服务器向外扩展时。

在本文中，我们探究了调优您的 LAMP 性能的 5 种简单方法。我们不仅通过利用一个操作码缓存和优化 PHP 配置探究了 PHP 级别的技术，而且探究了如何优化您的数据库设计来实现合理的索引编制。我们还探讨了如何利用一个用户缓存（以 APC 为例）来展示如何在数据不经常改变时避免重复的数据库调用。

加载全部内容
相关教程
猜你喜欢
用户评论