向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除|赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.

一大早，一个年轻的程序员问大师：

“我准备写一些单元测试用例。代码覆盖率应该达到多少为好？”

大师回答道:

“不要考虑代码覆盖率，只要写出一些好的测试用例即可。”

年轻的程序员很高兴，鞠躬，离去。

之后没多久，第二个程序员问了大师同样的问题。

大师指着一锅烧沸的水说：

“我应该往这个锅里放多少米？”

这个程序员看起来被难住了，回答道：

“我怎么会有答案？这取决于要给多少人吃，他们饿不饿，有什么菜，你有多少米，等等。”

“完全正确，” 大师说。

第二个程序员很高兴，鞠躬，离去。

末了，来了第三个程序员问了大师同样的关于代码覆盖率的问题。

“百分之八十，不能少！” 大师一拳锤在桌子上，用严厉的口气回答道。

第三个程序员很高兴，鞠躬，离去。

回复完这个之后，一个年轻的实习生走到大师身边：

“大师，今天我无意中听到了你对同一个代码覆盖率问题给出了三个不同的答案。为什么？”

大师从椅子上站起来：

“给我泡点新茶，我们聊聊这个。”

当杯子里倒满了冒着热气的绿茶后，大师开始说：

“这第一个程序员是个新手，刚刚开始学测试。目前他有大量的程序都没有测试用例。他有很长的路要走；现在对他要求代码覆盖率只会打击他，没有什么用处。最好是让他慢慢的学会写一些测试用例，测试一下。他可以以后再考虑代码覆盖率。”

“而这第二个程序员，不论对编程还是测试都是十分的有经验。我以问作答，问她应该往锅里放多少米，使她明白决定测试用例多少的因素有很多，她比我更知道这些因素——毕竟是她自己的代码。对这个问题没有一个简单的、直接的答案。以她的聪明完全能明白这个道理，正确的完成任务。”

“我明白了，” 年轻的实习生说， “但是如果没有一个简单直接的答案，那你为什么告诉第三个程序员‘百分之八十，不能少’呢？”

大师笑的前仰后合，绿茶都喷了出来。

“这第三个程序员只想得到一个简单的答案——即使根本没有简单的答案 … 而且即使有答案她也不会按答案做。”

年轻的实习生和头发斑白的大师在沉思中喝完茶。

MYSQL导出一个SQL后:
DELIMITER $$
DROP TRIGGER IF EXISTS `updateegopriceondelete`$$
CREATE
    TRIGGER `updateegopriceondelete` AFTER  DELETE ON  `customerinfo`
    FOR EACH ROW BEGIN
DELETE FROM egoprice  WHERE customerId=OLD.customerId;
    END$$
DELIMITER ;

其中DELIMITER 定好结束符为"$$", 然后最后又定义为";", MYSQL的默认结束符为";".

阅读全文

如何进行实际分区  
看看分区的实际效果吧。我们建立几个同样的MyISAM引擎的表，包含日期敏感的数据，但只对其中一个分区。分区的表（表名为part_tab）我们采用Range范围分区模式，通过年份进行分区：



注意到了这里的最后一行吗？这里把不属于前面年度划分的年份范围都包含了，这样才能保证数据不会出错，大家以后要记住啊，不然数据库无缘无故出错你就爽了。那下面我们建立没有分区的表（表名为no_part_tab）：  




下面咱写一个存储过程（感谢Peter Gulutzan给的代码，如果大家需要Peter Gulutzan的存储过程教程的中文翻译也可以跟我要，chenpengyi◎gmail.com），它能向咱刚才建立的已分区的表中平均的向每个分区插入共8百万条不同的数据。填满后，咱就给没分区的克隆表中插入相同的数据：


mysql> delimiter //  
mysql> CREATE PROCEDURE load_part_tab()  
  -> begin  
  -> declare v int default 0;  
  -> while v < 8000000  
  -> do  
  -> insert into part_tab  
  -> values (v,'testing partitions',adddate('1995-01-01',(rand(v)*36520) mod 3652));  
  -> set v = v + 1;  
  -> end while;  
  -> end  
  -> //  
Query OK, 0 rows affected (0.00 sec)  
mysql> delimiter ;  
mysql> call load_part_tab();  
Query OK, 1 row affected (8 min 17.75 sec)  
mysql> insert into no_part_tab select * from part_tab;  
Query OK, 8000000 rows affected (51.59 sec)  
Records: 8000000 Duplicates: 0 Warnings: 0  

表都准备好了。咱开始对这两表中的数据进行简单的范围查询吧。先分区了的，后没分区的，跟着有执行过程解析（MySQL Explain命令解析器），可以看到MySQL做了什么：  
mysql> select count(*) from no_part_tab where  
  -> c3 > date '1995-01-01' and c3 < date '1995-12-31';  
+----------+  
| count(*) |  
+----------+  
| 795181 |  
+----------+  
1 row in set (38.30 sec)  

mysql> select count(*) from part_tab where  
  -> c3 > date '1995-01-01' and c3 < date '1995-12-31';  
+----------+  
| count(*) |  
+----------+  
| 795181 |  
+----------+  
1 row in set (3.88 sec)  

mysql> explain select count(*) from no_part_tab where  
  -> c3 > date '1995-01-01' and c3 < date '1995-12-31'\G  
*************************** 1. row ***************************  
  id: 1  
select_type: SIMPLE  
  table: no_part_tab  
  type: ALL  
possible_keys: NULL  
  key: NULL  
  key_len: NULL  
  ref: NULL  
  rows: 8000000  
  Extra: Using where  
1 row in set (0.00 sec)  

mysql> explain partitions select count(*) from part_tab where  
  -> c3 > date '1995-01-01' and c3 < date '1995-12-31'\G  
*************************** 1. row ***************************  
  id: 1  
select_type: SIMPLE  
  table: part_tab  
  partitions: p1  
  type: ALL  
possible_keys: NULL  
  key: NULL  
  key_len: NULL  
  ref: NULL  
  rows: 798458  
  Extra: Using where  
1 row in set (0.00 sec)  
从上面结果可以容易看出，设计恰当表分区能比非分区的减少90％的响应时间。而命令解析Explain程序也告诉我们在对已分区的表的查询过程中仅对第一个分区进行了扫描，其他都跳过了。  

chown -R jackxiang changan***.act  
解决方法：也就是把上层目录给予权限赋予为自己即可。

在send(),recv()过程中有时由于网络状况等原因，收发不能预期进行,而设置收发超时控制：
在Linux下需要注意的是时间的控制结构是struct timeval而并不是某一整型数，以下是来自于网上一篇文章中的摘录，它是这样写的：
int nNetTimeout=1000;//1秒，
//设置发送超时
setsockopt(socket，SOL_SOCKET,SO_SNDTIMEO，(char *)&nNetTimeout,sizeof(int));
//设置接收超时
setsockopt(socket，SOL_SOCKET,SO_RCVTIMEO，(char *)&nNetTimeout,sizeof(int));
这样做在Linux环境下是不会产生效果的，须如下定义：struct timeval timeout = {3,0};
//设置发送超时
setsockopt(socket，SOL_SOCKET,SO_SNDTIMEO，(char *)&timeout,sizeof(struct timeval));
//设置接收超时
setsockopt(socket，SOL_SOCKET,SO_RCVTIMEO，(char *)&timeout,sizeof(struct timeval));
有两点注意就是：
1）recv ()的第四个参数需为MSG_WAITALL，在阻塞模式下不等到指定数目的数据不会返回，除非超时时间到。还要注意的是只要设置了接收超时，在没有MSG_WAITALL时也是有效的。说到底超时就是不让你的程序老在那儿等，到一定时间进行一次返回而已。
2）即使等待超时时间值未到，但对方已经关闭了socket， 则此时recv()会立即返回，并收到多少数据返回多少数据。
来源：http://blog.csdn.net/newger/archive/2008/05/19/2459113.aspx

上面两个都可以，我都试过了，呵呵

获取libmemcached包

http://tangent.org/552/libmemcached.html

右下角有个source

下载

./configure


configure: error: “could not find memcached binary”

http://memcached.org/

下载memcache..

./configure

make && make install

http://monkey.org/~provos/libevent/ (可能需要libevent)

安装了memcached以后，继续configure libmemcached

./configure

make && make install

下载PHP memcached 支持

http://pecl.php.net/package/memcached

~phpbin/phpize

./configure –with-php-config=~phpbin/php-config

make && make install

改了php.ini后

phpinfo()输出:

memcached

memcached support enabled

Version 1.0.0

libmemcached version 0.37

Session support yes

igbinary support no

addServer(’10.10.10.50′, 11311);

function microtime_float()

{

list($usec, $sec) = explode(” “, microtime());

return ((float)$usec + (float)$sec);

}

$time_start = microtime_float();

for($i=0;$i<10000;$i++) { $m->set(‘int’, 99);

$m->set(‘string’, ‘a simple string’);

$m->set(‘array’, array(11, 12));

/* expire ‘object’ key in 5 minutes */

$m->set(‘object’, new stdclass, time() + 300);

//$m->get(‘int’);

//$m->get(‘string’);

//$m->get(‘array’);

//$m->get(‘object’);

}

$time_end = microtime_float();

$time = $time_end – $time_start;

echo “Did nothing in $time seconds\n”;

把第一行memcache改成memecached就能改了

我的实际测试结果

1万次读写 memcache:memcached 12:11

1万次只写，memcache:memcached 7:5

1万次只读 memcache:memcached 5.1:4.6

差距不大，而且memcached读取’object’这个key的时候居然报错了 Warning: Memcached::get(): unknown payload type in

这个应该是memcache写入的stdclass模式和memcached写入的格式不同，所以导致memcached读的时候出了问题。

总的来说libmemcached是全面胜出的，考虑到libmemcached还提供更多的接口，还是准备更换了！

libenv:: http://www.monkey.org/~provos/libevent/

wget http://www.monkey.org/~provos/libevent-1.4.13-stable.tar.gz

tar -zxvf libevent-1.4.13-stable.tar.gz

cd libevent-1.4.13-stable

./configure && make && make install

cd ..

tar -zxvf memcached-1.4.4.tar.gz

cd memcached-1.4.4

./configure && make && make install

cd ..

tar -zxvf libmemcached-0.37.tar.gz

cd libmemcached-0.37

./configure && make && make install

cd ..

tar -zxvf memcached-1.0.0.tgz

cd memcached-1.0.0

/usr/local/php/bin/phpize && ./configure –with-php-config=/usr/local/php/bin/php-config && make && make install

cd ..

vi /usr/local/php/etc/php.ini


来源：http://blog.fabrichina.net/archives/157

安装盘一： suse/i586/rzsz-0.12.20-853.2.i586.rpm
树莓派rz sz apt-get包:
sudo apt-get install lrzsz

CentOS6.5:
sudo yum install lrzsz  

公司编号 404109
公司名称 重庆石柱公司
所在省市 重庆市,重庆市
联系电话 023-73344888,18996912225
负责人 焦伟
地址 重庆市石柱县二环路国税局斜对面
派送范围 石柱县：县城内。
不派送范围 乡镇、村组及其它不派送
所开通的增值业务 预付款； 网上支付；  



公司编号 400013
公司名称 重庆丰都公司
所在省市 重庆市,重庆市
联系电话 023-70638886
负责人 彭洪峰
地址 重庆丰都县三合镇平都大道东段91号广电局正对面
派送范围 丰都县：县城内（三合镇城区范围内），南天湖东路，东升路，龙河路，沙湾路，雪玉路，庙坡路，商业一路，商业二路，南天湖中路。河北中路，秀才路，延生路，世坪路，南天湖西路，新凯路，双桂路，峡南溪路，平都大道，平都大道东段，中段，西段，滨江东路，中路，西路，名山大道，四环路。
【更新时间：2009-10-28 16:13_j】

不派送范围 丰都新城，湛普镇，双路镇，兴义镇，名山镇，包鸾镇，龙河镇，社坛镇，崇兴镇，高家镇，十直镇，长江大桥，看守所和其他乡镇村组不派送。
【更新时间：2009-10-28 16:13_j】

所开通的增值业务 预付款； 到付业务； 网上支付；  

php  /data/www/GatewayWorker-Zhuanye/start.php status
Workerman[/data/www/GatewayWorker-Zhuanye/start.php] status
----------------------------------------------GLOBAL STATUS----------------------------------------------------
Workerman version:3.5.3          PHP version:7.0.5
start time:2019-04-25 11:34:13   run 34 days 21 hours  
load average: 0.01, 0, 0         event-loop:\Workerman\Events\Event
1 workers       8 processes
worker_name  exit_status      exit_count
zhuanye      64000            149
----------------------------------------------PROCESS STATUS---------------------------------------------------
pid     memory  listening                 worker_name  connections send_fail timers  total_request qps    status
42782   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633711       0      [idle]
42820   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633708       0      [idle]
42822   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633710       0      [idle]
42824   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633757       0      [idle]
42837   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633684       0      [idle]
42897   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633637       0      [idle]
42910   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633703       0      [idle]
42914   2M      websocket://127.0.0.1:943 zhuanye      49          0         3       2633644       0      [idle]
/usr/local/php/bin/php /data/www/GatewayWorker-Zhuanye/start.php status | grep websocket | awk '{sum += $5;}END{print sum}'     392


root:~#cat cao
total 3164


-rw-r--r-- 1 root root     115 2010-03-13 01:24 awk
-rw-rw-rw- 1 root root  182870 2004-01-29 19:07 mp.xml
-rw-r--r-- 1 root root  210668 2010-03-03 14:49 6.zip
drwxr-xr-x 3 root root    4096 2009-11-22 13:35 arch
-rwxr-xr-x 1 root root      93 2010-03-09 16:49 co.sh
-rw-r--r-- 1 root root       0 2010-03-11 18:30 direct
-rwxr-xr-x 1 root root      73 2010-03-10 10:31 gesid.sh
-rwxr-xr-x 1 root root    1049 2010-03-10 14:06 getsh
-rw-r--r-- 1 root root     364 2010-03-13 02:27 hosts
-rw-r--r-- 1 root root     125 2010-03-13 01:33 kv
-rw-r--r-- 1 root root      76 2010-03-12 11:31 message

:~# awk 'BEGIN{print "sum"}NR==3{if($2<$5){$9=$2+$5;print $9}}' cao
sum
182871


~# awk 'BEGIN{print "sum"}NR==3{if($2<$5){$9=$2+$5}}END{print $9}' cao
sum
###还有一个空行，注意###

注意下面第三条的解释。

1.首先AWK处理文本的时候 是一行一行的读，一行一行的处理
2.你加了NR==3这个条件，只有这个条件成立的时候才执行后面的action
3.END 是在所有文件读入完以后 再执行的action原因在于$9与sum不同。$9是字段引用，而sum是自定义变量。字段是随着记录而变化的，sum不会。

[~/bc]# vim baidu4    
90525+92610+91521+92438+90379+92213+93073+91301+93514+92292
command:

变为：
90525
92610
91521
92438
90379
92213
93073
91301
93514
92292

Linux下的vi换行符是  \r
特别注意：在完全用vi操作在linux下还是 \n

            //换行替换为逗号，来拼装sql等等。。。


awk列求和：







多列求和相除：
[~/add]# awk '{a+=$1;b+=$2} END{print a/1024,b/1024}'  add.txt
0.0820312 0.0751953




换行符‘\n’和回车符‘\r’的区别：
答案：
是的，顾名思义，换行符就是另起一行，回车符就是回到一行的开头，所以我们平时编写文件的回车符应该确切来说叫做回车换行符
---------------------------------------------------------------

在控制台程序里，回车的本意是将光标移动到屏幕最左边（此时光标的横坐标没有变），换行就是将光标移动到下一行（此时光标的纵坐标没有变）,两者结合起来就实现了回车(省略说法)效果。
---------------------------------------------------------------

这是DOS的吧。在UNIX中就有点不同了。
在UNIX中，用一个'\n'就可以做DOS中'\n''\r'做的事了。
---------------------------------------------------------------

起源是打字机啦，回车是将打字头复位，换行是将打字纸上卷一行。

。。。。
有些事情我们不光想了也做，开发了版本一直都没有上线。有一个很重要的原因是，我们发现顺序好像错了。就是当你想要去做这样一件事情的时候，你首先要有一个平台有很多用户，它有信息枢纽的作用，你才有可能去做后面的事情。如果你先做的是后面的事情，前面的事情没办法在后端的积累之后完全形成出来!

对一些大流量的web服务器来说，比较常见的问题就是time_wait会很多，起因大多都是apache里 keepalive 没开的原因，将这个开启，相对会少一些，但大流量时还是比较多，这里还有另外一个参数设置




如果不想time_wait不要太多，只要把这个值调低，就肯定不会超过了

但会出现一个新问题，就是在系统日志里，会很多类似这样的警告

Nov 27 15:50:01 localhost kernel: printk: 9498 messages suppressed.
Nov 27 15:50:01 localhost kernel: TCP: time wait bucket table overflow
Nov 27 15:50:06 localhost kernel: printk: 9562 messages suppressed.
Nov 27 15:50:06 localhost kernel: TCP: time wait bucket table overflow
Nov 27 15:50:11 localhost kernel: printk: 10120 messages suppressed.
Nov 27 15:50:11 localhost kernel: TCP: time wait bucket table overflow
Nov 27 15:50:16 localhost kernel: printk: 9182 messages suppressed.
Nov 27 15:50:16 localhost kernel: TCP: time wait bucket table overflow
Nov 27 15:50:21 localhost kernel: printk: 9626 messages suppressed.

这个警告其实不影响使用和性能，只是烦而已。我曾为避免这个提示，就将 net.ipv4.tcp_max_tw_buckets 调得很大，接着 time_wait 也就很大了。这也是上面这个问题，在网上搜索到的解决办法了。不想这个警告出现，重新编译内核，可以避免。

还有另一外问题，就是 fin_wait1 过多的问题，这个情况，一般的服务器上不会有。至少我的情况是这样

但在用了集群/负载均衡（LVS）中，下面的机器，就有这种情况，也曾为解决这个问题苦恼了挺久，经过今天的测试，也可以解决了。

只要在/etc/sysctl.conf 中加入

net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_retries2 = 5
net.ipv4.tcp_orphan_retries = 3
net.ipv4.tcp_reordering = 5
net.ipv4.tcp_retrans_collapse = 0

就会减少很多了，关键的是 net.ipv4.tcp_orphan_retries 这个

来源：http://meisw.51099.com/show-234-1.html

Linux shell 中FTP自动登录批量下载文件
从ftp服务器192.168.1.171上的/home/data 到本地的/home/databackup

!/bin/bash
ftp -v -n 192.168.1.171
user guest 123456
binary
cd /home/data
lcd /home/databackup
prompt
mget *
close
bye

FTP自动登录批量上传文件
从ftp服务器192.168.1.171上的/home/data 到本地的/home/databackup

#!/bin/bash
ftp -v -n 192.168.1.171 << END
user guest 123456
binary
hash
cd /home/data
lcd /home/databackup
prompt
mput *
bye
END


来源：http://user.qzone.qq.com/165162897/blog/1282641785?ptlang=2052

SUN RPC是对socket的封装，其底层适用TCP或是UDP协议来传输数据，本文讨论SUN RPC使用的超时和重传策略。

1.       总超时值：一个客户端等待其服务器的应答的总时间量。TCP和UDP都是用该值；
2.       重试超时：只用于UDP, 是一个客户等待其服务器的应答期间每次重传请求的间隔时间；

注：因TCP是可靠的面向连接的协议，有自己的一套机制来保证端到端的传输可靠性，故使用TCP建立的应用不需要考虑超时重传等问题。


默认的超时时间可以通过clnt_control函数获取，


printf("timeout = %d : timeout = %d\n", tv.tv_sec, tv.tv_usec);


其中，UDP的默认总超时值为-1，重传超时值为5s（unp书上说是15s）;

      TCP的默认总超时值为0（unp书上说是30s）；

      跟书上不同的地方应该是由于RPC的版本不同吧。
为了对这些数据进行验证，以square程序为例，通过改变clnt_call传递的TIMEOUT值及服务器端处理请求前的睡眠时间值，我做了几个实验：（超时值还可以通过clnt_control来指定，此时rpc_call忽略参数timeout）
1.       TIMEOUT = {2，0}，服务器端睡眠10s，使用tcp协议；
现象：客户端2s后提示call failed: rpc: time out，服务器接收到一次请求。
   分析： 与期望相吻合，应用请求超过总的超时值时返回。  

2.       TIMEOUT = {2, 0}, 服务器端睡眠10s，使用udp协议；

现象：客户端5s后提示call failed: rpc: time out，服务器接收到一次请求。

分析：不明白，不是2s就提示超时么。
于是，我猜测是不是使用udp时，总的超时值不能小于重传时间呢?  
做如下试验：通过clnt_control将UDP的重试时间改成10s，TIMEOUT值不变，仍为2s。
现象：客户端10s后提示call failed: rpc: time out，服务器接收到一次请求。  
分析：我的猜测可能是正确的，RPC在实现时将总的超时值设为重传值和TIMEOUT中的较大值，不过这仅仅是猜测，没有看过SUN RPC实现的代码，不敢往下断言。
3.       TIMEOUT = {25, 0}, 服务器睡眠10s，使用tcp协议；
现象：客户端10s后收到应答，服务器收到一次请求。
分析：与期望相符合，整个请求没有超出总的超时值。
4.       TIMEOUT = {25, 0}, 服务器睡眠10s，使用udp协议；
现象：客户端在快到11s时收到一个回复，而服务器收到三次请求。
分析：
l  0s时，客户端启动后发送请求，服务器端接受该请求，处理时睡眠10s；
l   5s时，客户端重发请求，服务器端接受该请求，等待第一个请求处理完后。
l  10s时，客户端再次发送请求，服务器端接受该请求，等待前两次请求处理完.
不到1s后，客户端收到回复，这是服务器对第一个请求的应答，程序结束。
l  20s后，服务器端处理完第二个请求；
l  20s后，服务器端处理完第三个请求；
服务器睡眠10s就返回结果，为什么客户端会发出第三次请求？
因为网络延时，服务器从收到第一个请求，到睡眠10s，处理数据，返回结果时已经是10s之后的事情了，而客户端在10s时就发送了第三次请求，并马上收到了服务器对第一次请求的应答数据。
以上是我对SUN RPC超时和重传机制的一点理解，望不吝赐教！


来源：http://blog.chinaunix.net/u2/87570/showart_2201021.html

串行通信的传送速率用于说明数据传送的快慢，波特率表示串行通信时每秒钟传送“位” 的数目，比如1秒钟传送1位，就是1波特。即1波特＝1bps (位/秒)
  串行通信常用的标准波特率在RS-232C标准中已有规定，如波特率为600、1200、2400、4800、9600、19200等等。 假若数据传送速率为120字符/秒，而每一个字符帧已规定为10个数据位，则传输速率为120×10＝1200位/秒，即波特率为1200，每一位数据传送的时间为波特率的倒数：
  T＝1÷1200＝0.833ms