易栈网-膘叔

这样typecho的SVN源代码更新对我来说，有几个比较重要的地方。其中有一点就是我向70提出来的（我无法改源码）
1、需要能够对插件变量直接修改值，而不是通过config方法的form方式提交（其实我是想用在数据库备份插件中的，记录上次备份时间，以前的话，恐怕只能到option表里找到这个key，并且update这个key对应的value了），该方法目前存在于Helper类中。
2、修正附件的所有权（r1449）

多看看project页面的source中的change，可以看到更多修改记录。好象你有意见也可以去issues里面提（一个人更新。太慢了。。。）

这张图很有意思，你是不是在其中感受到了什么 ？为什么我们做出来的东西客户总不满意？为什么总是要互相扯皮？原因呢？这张图表达了很多。

这个PDF确实不错。只是。。。没有介绍netbeans下如何调试。phped下也没有介绍。仅介绍了zendstudio for eclipse和pdt还有vim的调试。不过。。。还是有很用处的东西。

对于浏览器的测试，除了PHP方面的print_r,var_dump等。他也介绍了firephp这个firefox的插件（基于firebug，如果不知道firebug那我也没啥好说的了）

对于最后简单的测试时间花费，也是用的传统的microtime来取的。额。。。他用的是PHP4的写法。只是最后介绍phpUnit就有点简单了。

本地备份：php-debug-manual-public.pdf

来源网址：http://www.laruence.com/2010/06/21/1608.html

这是一篇比较老的文章，其实从情感上来说，我更愿意推荐手册上的介绍，但事实上，在一些PHP群中，有些朋友在问的时候，他们总是想不到翻手册的。嗯，英文的手册确实让人不太舒服，但，不可能在手册一出来就帮你翻译好的吧？事事都去期待别人，还不如把英文好好看看，再者，手册上的英文真的很简单的。
我不知道你们的手册是怎么样的，版本多少，但是我在我的手册里是有这么一个章节：

一共讲了5种情况，而且对于不能上传大文件也专门做了介绍，他是这么说的：

PHP is capable of receiving file uploads from any RFC-1867 compliant browser (which includes Netscape Navigator 3 or later, Microsoft Internet Explorer 3 with a patch from Microsoft, or later without a patch).

PHP also supports PUT-method file uploads as used by Netscape Composer and W3C's Amaya clients. See the PUT Method Support for more details.

OK，我知道你们不愿意看，所以我也不多说了，看中文版吧，原文来自于：http://www.sourcejoy.com/php_dev/PHP_upload.html。
PHP文件上传功能一般都是大家使用事先封装好的函数，要用的时候直接使用已封装的函数就完了，但有时候不能使用封装函数，还真不大能记住PHP的上传相关的东西，在此做个总结，以备后用。

1.表单部分
允许用户上传文件，在HTML表单的声明中要加上一个上传的属性：
enctype = 'multipart/form-data'
表单的method必须是POST
表单选项MAX_FILE_SIZE隐藏域用于限制上传文件大小，它必须放在文件表单元素前面，单位为字节。
如：
<form enctype='multipart/form-data' id='aa' name='aaa' method='post' action='xxx.php'>
<input type='hidden' name='MAX_FILE_SIZE' value='2621114' />
<input name='upload_file' type='file' />
</form>

2.处理上传文件
上传时，PHP收到关于该文件的信息数组，这些信息可以在$_FILES这个超级全局数组中找到。
如：如果表单中的文件输入框名字为upload_file，那么关于该文件的所有信息都包含在数组$_FILES['upload_file']里面。
如：客户上传了一个“aaa.jpg”的图片数组值如下：
name "p5pp.jpg" 上传时文件的名字
type “image/jpeg" 文件类型
tmp_name "/tmp/phpjksdf" 服务器端的临时文件名
error 上传错误的返回值
size 2045 文件实际大小

上面数组里面的error会返回不同的常量值，如下:
UPLOAD_ERR_OK 没有错误发生，文件上传成功
UPLOAD_ERR_INI_SIZE 文件大小超过了PHP.INI中upload_max_filesize选项限制的值
UPLOAD_ERR_FORM_SIZE 上传文件的大小超过了HTML表单中MAX_FILE_SIZE选项值。可在程序中检查表单$FILES ['up_file']['size']来处理
UPLOAD_ERR_PARTIAL 文件只有部分被上传
UPLOAD_ERR_NO_FILE 用户没有提供任何文件上传
上传后处理的具体例子：
if(!move_uploaded_file($_FILES['f']['tmp_name'],"uploads/".$_FILES['f']['name'].".jpg")){
echo "error";
}

函数：
move_uploaded_file 移动上传的临时文件到指定的目录下
例子：
move_uploaded_file('临时文件名','指定文件路径')

is_uploaded_file 判断是否是通过http Post上传的文件
例子:
if(!is_uploaded_file($_FILES['f']['tmp_name'])){
echo '非法';
}

3.相关参数
PHP上传设计到的php.ini中的参数：
file_uploads 是否允许上传文件，默认ON

upload_tmp_dir 上传文件防止的临时目录，未指定则使用系统默认位置

upload_max_filesize 允许上传文件的大小的最大值，默认为2M

post_max_size 控制采用POST方法进行一次表单提交中PHP所能接受的最大数据量，如果希望用PHP文件上传，则此值要改为比upload_max_filesize要大

max_input_time 以秒为单位对通过POST/GET/PUT方式接受数据时间进行限制。

memory_limit 为了避免正在运行的脚本大量使用系统内存，PHP允许定义内存使用限额。通过设置此参数来制定单个脚本程序可以使用的最大内存容量，应适当大于post_max_size值

max_execution_time 用来设置在强制终止脚本前PHP等待脚本执行完毕的时间，单位秒。次选项可限制死循环脚本，但当存在一个长时间的合法活动时（如：上传大文件），这项功能也会导致操作失败。这样情况下必须考虑将此变量增加。

4.考虑多文件上传
可以利用$_FILES数组就可以轻松实现多文件上传。$_FILES数组可以获取客户端表单里面所有的file域内容，从而获得所有在同一表单上传的文件。

5.突破上传的内存限制
方法一：
修改php.ini中memory_limit值，改为更大，如 64M
方法二：
使用Apache Rewrite方法，动态修改memory_limit的值。首先建立一个.htaccess文件，保存在上传文件程序的 当前目录即可.代码如下：
php_value memory_limit 100M
php_value post_max_size 30M
php_value upload_max_filesize 30M
php_value max_execution_time 300
php_value max_input_tim 300
php_value display_errors On
——EOF——
当然，如果你在这种下也还是看不懂不能理解的话，我也就没有话说喽。

原文在这里：http://www.bopor.com/?p=652，我只是做个简单的转述。主要是因为这种架构在单台服务器上也可以做个参考，比如队列，当我一台服务器承受不了太大的访问时，我可以先把很多东西扔到队列里去，交由后台执行（当然是指一些比较重要而又不需要即时显示的。比如图片处理等 ）

OK，不多说了，直接上原文的重点为：

分库设计，数据库拆分

分库会给你在应用的开发和部署上都带来很多麻烦。
· 不能执行跨库的关联查询
· 不能保证数据的一致/完整性
· 所有查询必须提供数据库线索
· 自增ID

我这里只有一个小纲要，更多还是看原文吧。

最后介绍一下Yupoo的资料：

作为国内最大的图片服务提供商之一，Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下：
带宽：4000M/S (参考)
服务器数量：60 台左右
Web服务器：Lighttpd, Apache, nginx
应用服务器：Tomcat
其他：Python, Java, MogileFS 、ImageMagick 等

关于 Squid 与 Tomcat
Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是”目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了”
对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。

名词解释：
YPWS–Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
YPFS–Yupoo File System 与 YPWS 类似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

【Updated: 有网友留言质疑 Python 的效率，Yupoo 老大刘平阳在 del.icio.us 上写到 “YPWS用Python自己写的，每台机器每秒可以处理294个请求, 现在压力几乎都在10％以下”】

图片处理层
接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。
我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权原因而不用了（?）；EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是非常建议 Yupoo! 针对 EXIF 做些文章，这也是潜在产生受益的一个重点。
图片存储层
原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS 方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo! 今后发展需要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB 计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在 MogileFS 中。
对于其他部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。