Bankie Blog

转自：http://blog.jobbole.com/82908/ 看到这篇文章不错，转来收藏 依赖管理 依赖和包管理库 Composer/Packagist：一个包和依赖管理器 Composer Installers：一个多框架Composer库安装器 Pickle：一个PHP扩展安装器   其他的依赖管理 其他的相关依赖管理 Satis：一个静态Composer存储库生成器 Composition：一个在运行时检查Composer环境的库 Version：语义版本的解析和比较库 NameSpacer -转化下划线到命名空间的库 Patch Installer -使用Composer安装补丁的库 Composer Checker -校验Composer配置的工具   框架 Web开发框架 Symfony2 -一个独立组件组成的框架 Zend Framework 2 -另一个由独立组件组成的框架 Laravel 4 -另一个PHP框架 Aura PHP -独立组件的框架 Yii2 – 另一个PHP框架 Nette – 另一个由个体组件组成的框架 PPI Framework 2 -一个互操作性框架 Phalcon -通过C扩展实现的框架 其他框架 其他Web开发框架 Symfony CMF – 创建自定义CMS的内容管理框架 Knp RAD Bundle -Symfony 2的快速应用程序（RAD）包 框架组件 来自web开发框架的独立组件 Symfony2 Components -Symfony2组件 Zend Framework 2 Components -ZF2组件 Aura Components -PHP5.4组件包 Hoa Project -另一个PHP组件包 微型框架 微型框架和路由 Silex – 基于Symfony2组件的微型框架 Slim – 另一个简单的微型框架 Bullet PHP -用于构建REST APIs的微型框架 Fast Route – 快速路由库 Pux -另一个快速路由库   其他微型框架 其他相关的微型框架和路由 Silex Skeleton -Silex的项目架构 Silex Web Profiler -Silex web调试工具条 Stack – Silex/Symfony的可堆叠中间件库 Slim Skeleton -Slim架构 Slim View -Slim的自定义视图集合 Slim Middleware -Slim的自定义中间件集合 模板 模板化和词法分析的库和工具 Twig -一个全面的模板语言 Twig Cache Extension -一个用于Twig的模板片段缓存库 Mustache -一个Mustache模板语言的PHP实现 Phly Mustache -另一个Mustache模板语言的PHP实现 MtHaml – 一个HAML 模板语言的PHP实现 PHPTAL -一个 TAL 模板语言的PHP实现 Plates -一个原生PHP模板库 Lex -一个轻量级模板解析器 静态站点生成器 预处理工具来生成web页面的内容。 Sculpin -转换Markdown和Twig为静态HTML的工具 Phrozn – 另一个转换Textile，Markdown和Twig为HTML的工具 HTTP 用于HTTP和网站爬取的库 Guzzle -一个全面的HTTP客户端 Buzz -另一个HTTP客户端 Requests -一个简单的HTTP库 HTTPFul -一个链式HTTP库 Goutte -一个简单的web爬取器 PHP VCR -录制和重放HTTP请求的库   URL…

转自 ：http://www.oschina.net/news/50112/how-hhvm-improve-php-performance 看了一下这篇文章不错，转过来了。 背景 HHVM 是 Facebook 开发的高性能 PHP 虚拟机，宣称比官方的快9倍，我很好奇，于是抽空简单了解了一下，并整理出这篇文章，希望能回答清楚两方面的问题： HHVM 到底靠谱么？是否可以用到产品中？ 它为什么比官方的 PHP 快很多？到底是如何优化的？ 你会怎么做？ 在讨论 HHVM 实现原理前，我们先设身处地想想：假设你有个 PHP 写的网站遇到了性能问题，经分析后发现很大一部分资源就耗在 PHP 上，这时你会怎么优化 PHP 性能？ 比如可以有以下几种方式： 方案1，迁移到性能更好的语言上，如 Java、C++、Go。 方案2，通过 RPC 将功能分离出来用其它语言实现，让 PHP 做更少的事情，比如 Twitter 就将大量业务逻辑放到了 Scala 中，前端的 Rails 只负责展现。 方案3，写 PHP 扩展，在性能瓶颈地方换 C/C++。 方案4，优化 PHP 的性能。 方案1几乎不可行，十年前 Joel 就拿 Netscape 的例子警告过，你将放弃是多年的经验积累，尤其是像 Facebook 这种业务逻辑复杂的产品，PHP 代码实在太多了，据称有2千万行（引用自 [PHP on the Metal with HHVM]），修改起来的成本恐怕比写个虚拟机还大，而且对于一个上千人的团队，从头开始学习也是不可接受的。 方案2是最保险的方案，可以逐步迁移，事实上 Facebook 也在朝这方面努力了，而且还开发了 Thrift 这样的 RPC 解决方案，Facebook 内部主要使用的另一个语言是 C++，从早期的 Thrift 代码就能看出来，因为其它语言的实现都很简陋，没法在生产环境下使用。 目前在 Facebook 中据称 PHP:C++ 已经从 9:1 增加到 7:3 了，加上有 Andrei Alexandrescu 的存在，C++ 在 Facebook 中越来越流行，但这只能解决部分问题，毕竟 C++ 开发成本比 PHP 高得多，不适合用在经常修改的地方，而且太多 RPC 的调用也会严重影响性能。 方案3看起来美好，实际执行起来却很难，一般来说性能瓶颈并不会很显著，大多是不断累加的结果，加上 PHP 扩展开发成本高，这种方案一般只用在公共且变化不大的基础库上，所以这种方案解决不了多少问题。 可以看到，前面3个方案并不能很好地解决问题，所以 Facebook 其实没有选择的余地，只能去考虑 PHP 本身的优化了。 更快的 PHP 既然要优化 PHP，那如何去优化呢？在我看来可以有以下几种方法： 方案1，PHP 语言层面的优化。 方案2，优化 PHP 的官方实现（也就是 Zend）。 方案3，将…

图片上传一般是用form表单的，类型  enctype=”multipart/form-data”>用ajax一般 两种方法一种是动态创建表单，提交到iframe里，然后进行处理 ，下面介绍另一种方式 html 里必须要有type=”file”  的input 传输stream html代码如下： [well] <div class=”contentinner”> <ul> <!– <li> <img src=”../../images/cs.jpg” alt=””/> <em></em> </li> –> <li> <span class=”b_addpic”></span> <input type=”file” name=”Filedata” multiple=”multiple” id=”Filedata”/> </li> </ul> </div> [/well]   JS处理方式如下： //要注意的是ajax两个属性取值是 processData:false, contentType : false,否则后台取不到 GET 或POST的数据 [well] function upload(){ var img= new FormData(); var pic = $(“Filedata”); var fileObj= pic.get(0).files; //console.log(fileObj); img.append(“gimg”, fileObj[0]); $.ajax({ url : ‘http://test.vogue.qq.com/Uploadpic/Upload/’, data : img, cache:false, processData:false, contentType : false, dataType : ‘json’, type : “POST”, success:function(data){ var _getdata = data.url; var _htmlcon = “”; for(var i in _getdata){ _htmlcon += ‘<li>’; _htmlcon += ‘<img src=”‘+_getdata[i]+'” alt=””><em></em>’; _htmlcon += ‘</li>’; } comment.numPic = _getdata.length + comment.numPic; if(comment.numPic < 5){ $(“.imgcontent”).find(“ul”).prepend(_htmlcon);…

近期读 《构建高性能WEB站点(完整版)》这本书，其中有很多技术平时虽然遇到过，但也没有具体记录过程，就此机会做笔录。   一、DNS负载均衡 [well] 最先接触负载之一，如果有自己的DNS服务器，这种方式很好实施的。实现也很简单。增加多个A记录或者使用cname 例如： facebook.com. 2254 IN A 69.63.176.140 facttbook.com. 2254 IN A 69.63.178.11 facebook.com• 2254 IN A 69.63.184.142 但是问题一般不会有自己的DNS服务，而使用服务商的DNS服务时，缓存太严重还不一定支持多条A记录，记得万维网的DNS服务生效可能有一天时间，这样对业务影向太大。 原文描述： DNS服务器充当了一个粗放型的済求调度器，这给我们带来了一些遗憾，在这种 情况下，如何让多台实际服务器最大程度地保持比较均衡的负载，是我们筘要持续考虑的 问题。 这里顺便说一下，所谓的“均衡”，不能狭义地理解为分配给所有实际服务器的工作量一 样多，因为有时候，多台服务器的承载能力各不相同，这可能体现在硬件配置、网络带宽 的差异，也可能因为某台服务器身兼多职，我们所说的“均衡”，也就是希望所有服务器 都不要过载，并且能够最大程度地发挥作用。 二、反向代理负载均衡 常用负载技术，还可以根据权重分配real server这个是DNS方式解决 不了，也可以做为缓存使用， Nginx,作为反向代理服务器， 也就是负载均衡调度器，并为它配置两个后端服务器，如下所示： upstream backend { server 10.0.1.200:80; server 10.0.1.201:80; } 以上的配置只是这里提到的关键部分，更多的配置你可以查阅Nginx的官方文档，里面有 很详细的介绍。 对反向方式 权重比率非常重要，本文指出独立服务器处理能力的比率是吞吐率最好配置 缺点：对于反向代理本身的处理能力，文章指出： 我们知道反向代理服务器工作在HTTP层面，对于所有HTTP请求都要亲自转发，可谓是 大事小事亲历亲为，这也让我们为它捏了一把冷汗，你也许在怀疑它究竟有多大能耐，能 支撑多少后端服务器，的确，这直接关系到整个系统的扩展能力。 而且，个人感觉，做为反向代理，又接收HTTP还要转发处理 ，其并发处理能力会有折扣。 三、Netfilter/iptables 摘录文章描述： 从Linux 2.4内核开始，其内置的Netfilter模块便肩负起这样的使命，它在内 核中维护着一些数据包过滤表，这些表包含了用于控制数据包过滤的规则。 我们知道，当网络数据包到达服务器的网卡并且进入某个进程的地址空间之前，先要通过 内核缓冲冈，这时候内核中的Netfilter便对数据包有着绝对控制权，它可以修改数据包， 改变路由规则。 既然Netfilter工作在内核中,我们看不见摸不着,那么如何让它按照我们的需要來工作呢？ Linux提供了 iptables，它是工作在用户空间的一个命令行工具，我们可以通过它来对 Netfiltei•的过滤表进行插入、修改或删除等操作，也就是建立了与Netfilter■沟通的桥梁， 告诉它我们的意图。 那么，我们要做的就是让Linux服务器成为连接外部网络和私有网络的路由器，俏这不是 普通的路由器，我们知道路由器的工作是存储转发，除了修改数据包的MAC地址以外， 通常它不会对数据包做其他手脚，而我们要实现的路由器恰恰是要对数据包进行必要的修 改，包括来源地址和端口，或者目标地址和端n。 总之，Linux内核改变数据包命运的惊人能力，决定了我们可以构建强大的负载均衡调度 器，将请求分散到其他实际服务器上。 说到iptables,最多的应用场景就是防火墙了，我几乎为每台Linux服务器都毫不犹豫地 进行iptables防火墙配置，比如以下这段简单的iptables规则： iptables -F INPUT iptables -A INPUT -i ethO -p tcp –dport 80 -j ACCEPT iptables -P INPUT DROP 它完成了熏要的任务，那就是告诉内核只允许外部网络通过TCP与这台服务器的80端U 建立连接，这项规则可以很好地用在Web服务器上。 另外，我们还会用iptables来实现本机端口重定向，比如以下的规则.• iptables -t nat -A PREROUTING -i ethO -p tcp —dport 80 -j REDIRECT —to-port 8000 它将所有从外部网络进入服务器80端U的请求转移到了 8000端口，这有什么意义呢？当 然是隐藏某些服务的实际端口，同时也便于将一个端口快速切换到其他端口的服务上，提 高端口管理的灵活性。 关键的时刻到了，我们将用iptables来实现NAT，在此之前，我们需要执行以下的命令行 操作： echo 1 > /proc/sys/net/ipv4/ip_forward 这意味着该服务器将被允许转发数据包，这也为它成为NAT服务器提供了可能。 接下来，我们在作为调度器的服务器上执行以下的iptables规则： iptables -t nat -A PREROUTING -i ethO -p tcp –dport 8001 -j DNAT –to-destination 10.0.1.210:8000 这条规则几乎完成了所有DNAT的实现，它将调度器外网网卡上8001端口接收的所有请 求转发给10.0.1.210这台服务器的8000端口，至于转发的具体过程，前面我们已经详细 介绍过，在此不再赘述。 同样，我们在调度器上执行以下的iptables规则： iptables -t nat -A PREROUTING -i ethO -p tcp –dport 8002 – j DNAT –to-destination 10.0.1.211:8000 不用多说，这条规则你一定明白了。 这两条规则已经进入了 Netfiltei•的过滤表，我们可以通过iptables命令来查看它们，如下 所示： s-director:- # iptables -nL -t nat Chain PREROUTING (policy ACCEPT) Target prot opt source destination DNAT tcp — 0.0.0.0/0 0.0.0.0/0 tcp <^>t:8001 to:10.0.1.210:8000 DNAT tcp — 0.0.0.0/0 0.0.0.0/0 tcp<^>t:8002 to:10.0.1.211:8000 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination 可以看到，转发规则己经存在，但是还缺少一个环节，这至关重要，我们必须将实际服务 器的默认网关设置为NAT服务器，也就是说，NAT服务器必须为实际服务器的网关，否 则，数据包被转发后将一去不返。 添加默认网关非常容易，在实际服务器上执行以下命令行操作： route add default gw 10.0.1.50   现在，查看路由表，刚才的默认网关已经出现了:     s-rs:〜# route Kernel IP routing table Destination Gateway 10.0.1.0 * 125.12.12.0 * link-local * loopback * default 10.0.1.50     现在，我们终于可以通过调度器的800丨和8002端口分别将请求转发到两个实际服务器上， 可是，回想前面的问题，用iptables来实现负载均衡调度器，看起来有点困难，iptab丨es似 乎只能按照我们的规则来干活，没有调度器应该具备的调度能力和调度策略。 接下来，IPVS上场的时刻到了。 四、IPVS/ipvsadm  也可称LVS IPVS不仅可以实现基于NAT的负载均衡，同时还包括后面要介绍的直接路由和IP隧道 等负载均衡。令人振奋的是，IPVS模块己经内置到Umix2.6.x内核中,这意味着使用Linux 2.6.x内核的服务器将无须重新编译内核就可以直接使用它。 最重要的是了解 LVS的几种调度方式 RR、DR、TUN LVS-NAT中，我们使用了 RR调度策略，它是一种静态调度策略，当在集群中 实际服务器承载能力相当的环境下，它可以很好地实现均衡调度。同时，LVS也支持带权 重的RR调度，只需要配置实际服务器的weight值即可，当然，这也属于静态调度策略》 除此之外，LVS提供了一系列的动态调度策略，比如最小连接（LC)、带权重的最小连 接(WLC)、最短期望时间延迟（SED)等，它们都可以根据实际服务器的各种实时状态 做出调度决策，可谓是察言观色，全面兼顾。 LVS—DR，不同于NAT机制，直接路由方式下的负载均衡调度器工作在数据链路层（第二层），简 单地说，它通过修改数据包的目标MAC地址，将数据包转发到实际服务器上，并且最重 要的是，实际服务器的响应数据包将直接发送给用户端，而不经过调度器。即配置个虚拟IP （使用IP别名） real server 要在同一WAN网段，文章：LVS-DR非常适合搭建可扩展的负载均衡系统，不论是Web服务器还是文件 服务器，以及视频服务器，它都拥有出色的表现。但前提是，你必须为实际服务器购买一 系列的合法IP地址，不过，相比于负载均衡硬件设备，它们还是要便宜得多。 LVS－TUN， 也称为LVS-TUN。与LVS-DR不同的是，实酥服务器可以和调度器不在同一个 WAN网段，调度器通过IP隧道技术来转发请求到实际服务器，所以实际服务器也必须拥 有合法的IP地址。 基于IP隧道的请求转发机制，简单地说，它是将调度器收到的IP数据包封装在一个新的 IP数据包中，转交给实际服务器，然后实际服务器的响应数据包可以直接到达用户端。 总的来说，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，可以非常有效 地提高集群的扩展能力，但如何选择它们，更多的不是因为性能和扩展性，而是取决于你 的网络部署需要，比如刚才提到的CDN服务需要将实酥服务器部署在不同的IDC，从而必须使用IP隧道技术。 一般大型网站会混合使用上面几种技术，比如先DNS 负载。再LVS－NET，LVS—DR，LVS—TUN中型网站直接nginx反向/DNS就很适合，当然还少不了LVS+keepalived 做到易扩展，强容灾。 [/well]

一，安装步骤 1,官网下载leveldb 我的是 leveldb-1.13.0  安装省。 2,PHP下下载源码生成leveldb.so 配置php.ini 重起apache/nginx / php-m 查看是否安装成功 二，使用配置例子如下： [well]Well $options = array( ‘create_if_missing’ => true, // if the specified database didn’t exist will create a new one ‘error_if_exists’ => false, // if the opened database exsits will throw exception ‘paranoid_checks’ => false, ‘block_cache_size’ => 8 * (2 << 20), ‘write_buffer_size’ => 4<<20, ‘block_size’ => 4096, ‘max_open_files’ => 1000, ‘block_restart_interval’ => 16, ‘compression’ => LEVELDB_SNAPPY_COMPRESSION, ‘comparator’ => NULL, // any callable parameter which returns 0, -1, 1 ); /* default readoptions */ $readoptions = array( ‘verify_check_sum’ => false, ‘fill_cache’ => true, ‘snapshot’ => null ); /* default write options */ $writeoptions = array( ‘sync’ => false ); /*…