最新 | 最热门 | 最高评价

+0  学习搭建Python环境

Tag: Technical | Python
老王 发于 2013年07月23日 22:09 | 点击: 1180 | 展开摘要
写了好多年的PHP代码,不免有些许的厌倦,是时候学一门新语言了,这就好比对男人来说,家里的女人看得久了,新鲜感荡然无存,自然想纳几房小妾,不过对于身处河东狮吼险境的我而言,此等美梦注定遥不可及,还是老老实实学编程吧,想当年我还像模像样的学过Python,可惜没坚持下来,希望这次能行。

闲言碎语不要讲,表一表Python的安装,操作系统为CentOS,因为版本旧,加之已经包含了Python-2.4.3,所以我换了一个路径安装了Python-2.7.5,目前此版本比较通用:

查看全文: http://www.udpwork.com/item/10277.html

+0  请注意PHP程序里的敏感信息

Tag: Technical | PHP
老王 发于 2013年07月19日 17:01 | 点击: 2087 | 展开摘要
何为敏感信息?简单点来说就是你不想让别人知道的信息,比如说数据库的地址,用户名,密码等等,此类信息往往知道的人越少越好。

通常,PHP程序里的配置文件大致如下所示:

<?php

return array(
'database' => array(
'host' => '192.168.0.1',
'username' => 'administrator',
'password' =&

查看全文: http://www.udpwork.com/item/10222.html

+0  MySQL优化的奇技淫巧之STRAIGHT_JOIN

Tag: Technical | MySQL
老王 发于 2013年06月04日 23:37 | 点击: 1648 | 展开摘要
最近没怎么搞SQL优化,碰巧数据库被慢查询搞挂了,于是拿来练练手。

问题

通过「SHOW FULL PROCESSLIST」语句很容易就能查到问题SQL,如下:

SELECT post.*
FROM post
INNER JOIN post_tag ON post.id = post_tag.post_id
WHERE post.status = 1 AND post_tag.tag_id = 123
ORDER BY post.created DESC
LIMIT 1

查看全文: http://www.udpwork.com/item/9974.html

+0  如何诊断CDN故障

Tag: Technical | CDN
老王 发于 2013年05月23日 20:19 | 点击: 1252 | 展开摘要
某项目使用CDN做文件下载服务,最近不时有网友反馈下载出错,因为CDN是第三方提供的,且节点众多,所以诊断起来有点麻烦,必须想想招儿。

首当其冲的问题是如何确认CDN有哪些节点?

幸运的是通过阿里测提供的服务,我们能拿到这个IP列表,当然这个IP列表不可能百分百完整,不过应该包含了大部分的节点,有兴趣的可以参考百度的JQuery CDN例子。

需要说明的是阿里测偏重于测试国内的网络环境,如果你要测试的CDN偏重于国外的网络环境,可以考虑使用Just-Ping提供的服务。

查看全文: http://www.udpwork.com/item/9910.html

+0  笨法玩秒杀

Tag: Technical | MySQL | Redis
老王 发于 2013年05月19日 22:07 | 点击: 1175 | 展开摘要
秒杀无异于一场自找的DDoS攻击,从这个角度来说:玩秒杀的电子商务网站,和那些不停喊着用力打我的受虐狂没有什么两样,因为他们都痛并快乐着。

在「中国数据库技术大会」上,淘宝分享了「秒杀场景下MySQL的低效」,详细分析了秒杀的技术难点及改进措施,简而言之,主要就是在高并发事务请求的情况下,数据库性能由于死锁检测等因素直线下降,在这种场景下,单纯的关闭死锁检测虽然可以提升一定的性能,但这顶多是治标而已,如何治本?淘宝给出来两个改进方法:

请求排队:如果请求一股脑的涌入数据库

查看全文: http://www.udpwork.com/item/9879.html

+0  笨法玩秒杀

Tag: Technical | MySQL | Redis
老王 发于 2013年05月19日 22:07 | 点击: 1457 | 展开摘要
秒杀无异于一场自找的DDoS攻击,从这个角度来说:玩秒杀的电子商务网站,和那些不停喊着用力打我的受虐狂没有什么两样,因为他们都痛并快乐着。

在「中国数据库技术大会」上,淘宝分享了「秒杀场景下MySQL的低效」,详细分析了秒杀的技术难点及改进措施,简而言之,主要就是在高并发事务请求的情况下,数据库性能由于死锁检测等因素直线下降,在这种场景下,单纯的关闭死锁检测虽然可以提升一定的性能,但这顶多是治标而已,如何治本?淘宝给出来两个改进方法:

请求排队:如果请求一股脑的涌入数据库

查看全文: http://www.udpwork.com/item/9862.html

+1  MySQL主从服务器数据一致性的核对与修复

Tag: Technical | MySQL
老王 发于 2013年05月03日 21:40 | 点击: 1304 | 展开摘要
我上一次遇到MySQL主从服务器数据一致性问题,想想是几年前的事情了,还依稀记得当时惊慌失措的情景,好在最后借助Maatkit解决了问题。几年后,当我再次面对同样的问题时,Maatkit已经不复存在,转而成为了Percona Toolkit的一部分,不变的是我依旧手忙脚乱,所以还是记录一下吧,保不准啥时候又会遇到这个问题。

如果你在MySQL从服务器上遇到类似下面的错误信息,那么恭喜你中招了:

mysql> SHOW SLAVE STATUS\G

Last_Err

查看全文: http://www.udpwork.com/item/9766.html

+0  被遗忘的Logrotate

Tag: Technical | Logrotate
老王 发于 2013年04月21日 13:42 | 点击: 1314 | 展开摘要
我发现很多人的服务器上都运行着一些诸如每天切分Nginx日志之类的CRON脚本,大家似乎遗忘了Logrotate,争相发明自己的轮子,这真是让人沮丧啊!就好比明明身边躺着现成的性感美女,大家却忙着自娱自乐,罪过!

Logrotate的介绍

显而易见,Logrotate是基于CRON来运行的,其脚本是「/etc/cron.daily/logrotate」:

#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf
EXITVAL

查看全文: http://www.udpwork.com/item/9695.html

+0  通过Nginx/Lua给Redis的PIPELINING减肥

Tag: Technical | Lua | Nginx | Redis
老王 发于 2013年03月24日 16:46 | 点击: 1474 | 展开摘要
某手机应用市场项目,其中请求量最大的功能是查询升级接口,具体点来说:客户端会不定期的把手机中应用名称及其应用版本发送到服务端,服务端通过比较版本来判断客户端的应用是否需要升级,如果需要就返回若干项相关信息。通常,一台手机里会装几十个到上百个应用不等,当海量客户端一起请求时,服务端的压力可想而知。

客户端请求的数据格式如下所示,可以采用GET或POST方法:

packages=foo|1&packages=bar|2&packages=<NAME>

查看全文: http://www.udpwork.com/item/9519.html

+0  一个替换问题

Tag: Technical | Linux
老王 发于 2013年03月22日 20:05 | 点击: 1061 | 展开摘要
今天碰到一个替换问题:需要把全部接口中出现的一个链接改成另一个链接。虽然链接地址是保存在数据库中的,但是由于某些原因,不能直接修改数据库中的内容,只能在渲染结果的时候再进行替换。

如果有很好的逻辑封装的话,这个问题并不是什么难事儿,可恰恰代码一团乱,搞不清楚到底哪些接口需要修改。我本打算依靠蛮力挨个文件查,但试了试发现工作量实在太大了,没办法只能想想别的招儿。

最后找到的招儿就是「tcpdump」,通过它可以直接过滤服务器渲染的内容:

shell> tcpdump

查看全文: http://www.udpwork.com/item/9511.html

+0  记一次丢包网络故障

Tag: Technical | Linux
老王 发于 2013年02月26日 19:18 | 点击: 1199 | 展开摘要
某台「Nginx / PHP」服务器时不时出现HTTP请求响应卡住的现象。

开始我怀疑PHP有问题,但是通过查询Nginx的access日志,发现里面记录的PHP响应时间「$upstream_response_time」非常小,此外还通过Strace命令仔细核对了是否存在耗时的操作,结果一无所获,所以基本排除了PHP的嫌疑。

BTW:关于Strace的介绍请参考我以前写的:DevOps的三板斧

接着我把目光转移到了Nginx身上,琢磨着是不是Nagle算法导致的网络延迟

查看全文: http://www.udpwork.com/item/9327.html

+0  HTTPKeepAlive,开启还是关闭

Tag: Technical | HTTP
老王 发于 2013年02月02日 18:14 | 点击: 1236 | 展开摘要
所谓「HTTP Keep-Alive」,在维基百科里称为「HTTP Persistent Connection」,说白了就是复用HTTP连接,如此一来理论上客户端的用户体验会更流畅,但是与之相对服务端不得不维持大量的连接。开启还是关闭,这是个问题。

一个经常用来讲解HTTPKeepAlive的例子一般是这样描述的:当我们访问一个包含了若干个图片的网页时,如果HTTPKeepAlive是关闭的,那么页面中每一个图片都会发起一次连接请求;但是如果HTTPKeepAlive是开启

查看全文: http://www.udpwork.com/item/9208.html
|<<<45678910>>>| 一共12页, 137条记录