Eclipse的本地PHP xdebug环境

Xdebug是一个很方便的PHP调试工具,它通过一系列的统计分析,可以简单明了的对PHP的各种调用进行记录和统计,方便开发者进行代码调试和性能调试。这次就将Xdebug和Eclipse的整合配置分享出来。

继续阅读“Eclipse的本地PHP xdebug环境”

推荐阅读:
一直用ubuntu作为自己的开
正如之前说的,很多情况下我们需
SVN虽说已经老了,可能逐步要

Web网站的几个并发量级

评价一个网站的“大小”,处于视角的不同,有很多种衡量的方法,类似文章数,页面数之类的数据非常明显,也没有什么可以争议的。但对于并发来说,争议非常之多,这里就从一个技术的角度开始,谈谈几个Web网站的数量级。

相信很多人谈论一个网站的热度,总免不了会询问日均PV,同时在线人数、注册用户数等运营数据,说实话从技术角度来说,这几个数值没有一个可以放在一起比较的——一个静态网站的PV跟一个SNS类/Web Game网站的PV根本就不是一回事。由于互联网有一个传说中的“3秒定律”,可能当下更多的网站技术指标要求1.5秒以内加载整页,或者至少可以达到阅读的标准。如果要较真什么“同时在线”,毫不客气的说,对于HTTP这类短链接的网络协议来说,在WebSocket还不普及的时代,能统计在线纯属扯淡,唯一能做的只是取个时间段,计算下访问用户而已。这些依然可以换算成QPS(Quest Per Second每秒请求数)。就并发而言,我唯一推崇的只有理论最大QPS和悲观QPS。

继续阅读“Web网站的几个并发量级”

推荐阅读:
事出前些日子有人咨询我:“在某
时延 latency(亦称为延
似乎每次开头都要讲述一下计算机

微博手机客户端转码后打开页面错乱的问题

碰到这样一种情况:在使用新浪微博共享一个页面连接之后,新浪会用一个短连接替换掉原来的长连接,然后发布这条微博。用户在浏览这条微博时,使用网页版本是没有任何问题的,但对于通过手机客户端访问之后,系统会自说自话的通过所谓的“精简模式”省略掉了页面中所有的CSS/JS效果,美其名曰“手机版”,以区别于“传统版”。很多页面将会出现错乱甚至于“白板”。例如下图:

继续阅读“微博手机客户端转码后打开页面错乱的问题”

推荐阅读:
评价一个网站的“大小”,处于视
种种原因,站长已经很久没有关注
Php-fpm由于其特有的优势

mod_php迁移到php-fpm的注意事项

Php-fpm由于其特有的优势已经逐渐成为这一阶段大负载网站的首选。近期受朋友之托,将一个稍显老旧的网站从apache+mod_php迁移到了nginx+php-fpm之上。其间碰到不少问题,除却php版本升级带来的兼容性问题之外,很多兼容性问题其实来自于php-fpm的特性。这里就简单的罗列一下所碰到的问题,以供大家参考,少走弯路为妙。

继续阅读“mod_php迁移到php-fpm的注意事项”

推荐阅读:
评价一个网站的“大小”,处于视
碰到这样一种情况:在使用新浪微
种种原因,站长已经很久没有关注

Key-Value式数据结构设计

近一年来始终专注于No-SQL技术和大并发下的数据结构。整理一下思路。

之前从事的行业以企业管理和电子商务系统为主,这样的系统比较注重于对于数据的描述和事物化的流程管理。这样的模式自然是SQL的强项,特别是企业信息化管理系统和电子商务中的帐务结算子系统,这类系统对于数据的原子性和一致性的要求近乎苛刻,根据CAP原则,只能放弃性能作为代价。后来辗转到互联网行业,特别是SNS的开发和运维中,很多思维模式必须要打破。SNS,特别是Feed部分的数据结构,绝对是SQL模式的噩梦——Feed分发、个性化增删改加上分库分表的物理结构让传统上的SQLDB疲于应付,即便实现成功,也始终无法摆脱“硬撑”的嫌疑。

继续阅读“Key-Value式数据结构设计”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
碰到一个悲催的事情:一台Red

Tornado的进程级别缓存用法

之前一直在跟朋友调试一个基于tornado框架的长连接HTTP服务,并不断的优化尽量以最少的资源换取最大的连接数。我的想法是通过定期轮询一个Redis键,当键值发生改变后推送信息给客户端,并同时回写改变数据到redis以便下次比对。这种方法中规中矩,但显然每次变动都会牵扯两次Redis读写,网络开销的代价很大。即便采用了Redis pipline连接池,受通讯时间的影响,性能只能说“可以接受”而已。瓶颈在数据存储的级别。

记得在PHP开发过程中,经常会用到实例级别或者线程级别的变量缓存,带来的性能提升是巨大的。但对于tornado来说,由于每次访问都会实例化tornado.web.RequestHandler,不能满足要求,只能考虑在主线程上进行变量缓存。一旦成功将有可能直接抛弃redis。

继续阅读“Tornado的进程级别缓存用法”

推荐阅读:
评价一个网站的“大小”,处于视
碰到这样一种情况:在使用新浪微
种种原因,站长已经很久没有关注

用Nginx和Redis搭建琐碎文件下载站

对于网站来说,琐碎文件是一个很鸡肋的问题。太多过小文件的管理总有这样那样的问题,特别是当文件数量到达临界时,甚至作一条ls或者rm都无法正常反应。而且正常情况下琐碎文件都会主动缓存,花费太多资源去实现意义也不大。

之前曾经通过nginx的memcache扩展,配合TokyoTyrant Server(每次都觉得很别嘴)这个即支持memcache协议,又可以持久化的Key-Value实现过琐碎文件的管理,但限于Memcache无法逾越的1M鸿沟,只能保存些小文件。

继续阅读“用Nginx和Redis搭建琐碎文件下载站”

推荐阅读:
评价一个网站的“大小”,处于视
碰到这样一种情况:在使用新浪微
种种原因,站长已经很久没有关注

非阻塞的Python web框架tornado

公司项目中需要使用长链接方式的获取后端数据库——主要是Redis的实时数据。

由于项目本身是PHP的初次看到这个项目,首先想到的是Apache + mod_php的方式,配合php的ob_start()方式直接调用,就如同我之前的一篇东西所说的那样。可问题不这么简单:

  1. 系统是nginx + php-fpm方式,php-fpm“hold不住”过多的Http请求,而nginx需要调整响应时间。
  2. 用户数量很多,Apache的消耗很大。本身功能点很小,实现成本不合算。 继续阅读“非阻塞的Python web框架tornado”
推荐阅读:
5月中旬,我参加了在加利福尼亚
之前发过一个帖子介绍了RDT在
继续在NUMA和性能差异的路上

开源小站的基础结构

之前有朋友问过开源小站的架构是怎样的,我回答道:“标准的wordpress,稍微做了一些调整。”时隔一段时期,几经搬迁,这次重新整理了一下开源小站的结构,就当分享罢了。

“开源小站”最初是基于drupal构建,基础数据库是postgresql。后来由于drupal的性能问题以及框死了的postgresql,只能整体迁移到了wordpress+mysql。当然迁移好之后,考虑到drupal和wordpress的链接地址的不同,修改了wordpress的部分代码,让之前的外链不至于失效。后来索性就通过apache的mod_rewrite模块添加了301跳转,wordpress的版本也可以随着“持续演进”了。

继续阅读“开源小站的基础结构”

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍

LAMP的常用扩展安装

之前已经弄过许多篇关于LAMP搭建的东西,都是基于最简单包的,这次说说几个比较常用扩展的安装:

继续阅读“LAMP的常用扩展安装”

推荐阅读:
5月中旬,我参加了在加利福尼亚
之前发过一个帖子介绍了RDT在
继续在NUMA和性能差异的路上