刚碰到一个问题，我写了一段脚本，然后代码检查了下是没有问题的，但是放到服务器上执行的时候，一直提示我使用的awk命令文件找不到(awk:No such file or directory)脚本大致这样（服务器上/bin/awk这个文件确实是存在的）： 12#!/bin/awk#下面脚本正文，略 后来找了半天，才发现这个脚本，最终被解析到的文本中，第一行被解析成了： 1#/bin

问题 需求排队到后面流于形式了，起到的效果甚微 一些不是很重要的任务，一拖再拖，产品对开发速度非常不满意 大家都去确认需求，耗费的时间成本太高了 部分项目存在单点问题，只有某个人会做；后面的需求变更非常依赖于该同事当前的任务队列 缺乏一个整体的需求管理人员，对于我们整个WEB用户端的需求没有把控住 需求队列文档的质量不够高，每次都是周一上午匆忙整理 解决方案 推行开发负责人机制，在最终需求和方案

应用场景比如一个前端页面发起的请求(请求A)，在服务端又请求了其他接口(请求B)，这样你调试的时候，就会因为不清楚请求B的情况，导致调试麻烦。比较常见的就是选股功能、问财接口相关的功能；这类功能，用户的请求到达服务端后，服务端还会再去请求行情/问财接口。 实现方案服务端将内部请求的参数，通过Header头输出，比如：header(“RequestParams:xxxxx”);注意名称不要

我们为什么要做压力测试？避免某天你正在家里悠闲地享受周末，或者在座位上正为自己写的某段代码感到兴奋时，某个人突然找到你，说：“完蛋了，XXX功能出问题了！” 事故记录2016.11.25 对外提供的接口，上线前未做压力测试，导致上线后云计算服务器因请求量过大而挂掉我们这边提供了一个数据接口给网站资讯组使用，因为双方开发沟通上的问题，导致网站那边在每次用户打开页面时，都会请求一次我们的这个接口；而网

问题描述我们的代码管理采用的是SVN+Apache的方式，通过http协议访问。当服务端输出中文信息时，客户端(乌龟)就会报错：output could not be translated from the native locale to UTF-8 原因排查是因为SVN+Apache的方式，Apache必须要有mod_dav_svn.so这个模块，且需要设置SVNUseUTF8 on。而我们内

先说明一下PHP对于url的编码方式：1.rawurlencode和rawurldecode这种方式会将特殊符号编码为%加上两位字母或者数字，空格会被编码为%20 2.urlencode和urldecode这种方式会将特殊符号编码为%加上两位字母或者数字，空格会被编码为+ 浏览器在发送请求时会自动进行 url 编码，这是传输协议规定的，且采用的是类似rawurlencode的方法，即空格会被编码为

升级理由php7相比老版本的php，性能提升非常大。 后端脚本测试123456我们的许多产品，都是采用后端脚本的形式生成数据，经多个实际项目测试，升级php7后能够极大的减少脚本运行时间。以一个项目中的实际脚本为例：脚本文件：/var/www/vis-free/applications/hk/scripts/cron/makeMarketDataHtml.php功能：获取港股市场代码，并请求行情数

前提条件先查看是否开启mod_proxy.so和mod_proxy_http.so模块，没有的话，开起来。如果没有编译，得自己编译下，此处略过。 配置文件12345678910111213141516171819202122NameVirtualHost *:83Listen 83<VirtualHost *:83> ServerName baksvn #ServerAdmin xxx

步骤## 假如我们的主服务器是10.0.7.2，从服务器是10.0.5.2，同步使用的svn账号是read 在从服务器上创建一个全新的代码库，并给read账号添加对该代码库的读写权限，然后开启svnserve进程 svnadmin create /home/zhangsan/svn/web /usr/local/subvers

一个真实的例子 200.105服务器要升级php7，为了测试程序兼容性，我想把200.105的请求抓下来，在测试服务器回放。 1234567891011121314151.抓取正式服务器200.105的请求包tcpdump -i eth0 tcp and port 80 -s 0 -w 200.105.cap2.将日志拷贝到205.233上面，这台部署了tcpcopy3.在205.235上面开启拦