作者归档：Young

Android Studio中使用Volley

Android上的通信框架各种各样，比如 android-async-http，而最近同学们很多都推荐给我用Google家的 Volley。

生成volley aar

官网上的指导手册说明了安装的步骤，首先自然是要下载源码：

git clone https://android.googlesource.com/platform/frameworks/volley

1	git clone https://android.googlesource.com/platform/frameworks/volley

然而在某些网络环境下，会出现SSL验证问题，这时候就需要暂时关闭git的SSL验证：

git config --global http.sslVerify false

1	git config --global http.sslVerify false

重新clone完成之后即可。

简单看看clone出的目录结构：

➜  volley git:(master) ls
Android.mk           build.xml            pom.xml              proguard.cfg         src
build.gradle         custom_rules.xml     proguard-project.txt rules.gradle

➜ volley git:(master) ls

Android.mk build.xml pom.xml proguard.cfg src

build.gradle custom_rules.xml proguard-project.txt rules.gradle

可以看到这里提供了通过gradle构建的方式，由于已经安装的Android Studio，那么在

~/.gradle/wrapper/dists/gradle-2.2-bin/ca0flae0itb57he40lyj6fhpp/gradle-2.2/bin/

1	~/.gradle/wrapper/dists/gradle-2.2-bin/ca0flae0itb57he40lyj6fhpp/gradle-2.2/bin/

这样的目录下可以找到gradle的可执行文件，不同版本的gradle可能不相同，但是位置应该是类似的。

找到gradle之后自然是进行build工作，不过在build之前，需要注意的是需要临时设定一下ANDROID_HOME环境变量，指向SDK目录：

export ANDROID_HOME=~/Library/Android/sdk

1	export ANDROID_HOME=~/Library/Android/sdk

同时还需要注意的是检查build.gradle文件中的buildToolsVersion为已安装的版本，即在SDK Manager中的Tools > Android SDK Build-tools中已安装的版本，目前配置文件中默认版本是21.1.0，可能与已安装的版本不同，如：

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.14.+'
    }
}

apply plugin: 'com.android.library'

android {
    compileSdkVersion 19
    buildToolsVersion = '21.1.2' //修改此处为对应的buildTools版本
}

apply from: 'rules.gradle'

buildscript {

repositories {

mavenCentral()

}

dependencies {

classpath 'com.android.tools.build:gradle:0.14.+'

}

apply plugin: 'com.android.library'

android {

compileSdkVersion 19

buildToolsVersion = '21.1.2' //修改此处为对应的buildTools版本

}

apply from: 'rules.gradle'

之后进行build工作：

~/.gradle/wrapper/dists/gradle-2.2-bin/ca0flae0itb57he40lyj6fhpp/gradle-2.2/bin/gradle build

1	~/.gradle/wrapper/dists/gradle-2.2-bin/ca0flae0itb57he40lyj6fhpp/gradle-2.2/bin/gradle build

如果build成功，会在当前目录下的build/outputs/aar目录下找到debug和release的aar包。

Android Studio引用Volley

在Android Studio中引用Volley的aar包在当前的1.1.0版本中是可以按照如下方式进行的，即修改项目的build.gradle文件，添加对aar包的引用：

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:21.0.3'
    compile(name:'volley', ext:'aar')
}


repositories{
    flatDir{
        dirs 'libs'
    }
}

dependencies {

compile fileTree(dir: 'libs', include: ['*.jar'])

compile 'com.android.support:appcompat-v7:21.0.3'

compile(name:'volley', ext:'aar')

}

repositories{

flatDir{

dirs 'libs'

}

在此之前，应该已经将volley-release.aar复制到项目的libs目录中并改名为volley.aar了。

完成之后就是愉快的coding了。

使用QtCreator配置C++ 11开发调试环境

发表回复

编译lwan的时候顺道看了下MinGW，发现64位版本也更新到了4.9，感觉自己很久没更新过Windows下的C++环境了，也想体验一下C++ 11，顺手升级了一下。

自己一直使用QtCreator作为C++开发环境，这个IDE个人很喜欢，自动补全功能相当方便，之前在开发Qt程序的时候这几乎是最好的选择，现在也开始出现了收费版本，但是仍然有社区版可用。目前CLion还没有放出正式版本，VS感觉又太重，QtCreator感觉还是一个很不错的选择。

QtCreator的是支持CMake的，正好自己想要学习CMake，于是打算选用CMake作为构建部分的工具。

以下是简要的配置步骤：

1.安装MinGW64

MinGW现在使用安装器的形式进行安装，下载完成一个很小的安装器后进行安装，期间可能是比较漫长的下载过程。不再多说。

2.安装CMake

一样是常规的安装步骤。

3.QtCreator配置

首先是配置编译器路径信息：

在工具->选项中进行配置：

配置编译器

之后配置GDB路径信息：

配置GDB

还需要配置上CMake路径信息：

配置CMake

上述步骤完成之后根据之前起好的别名（即上图中的Name字段），选择组成构建套件：

配置构建套件

4.项目级配置

首先自然是常规的新建项目了：

新建项目

在项目类型这里，需要选择使用CMake构建的纯C++项目：

新建使用CMake的纯C++项目

建立完成之后选择好保存的位置

确定项目保存位置

确认项目信息

之后开始配置Debug构建目录

配置Debug构建目录

之后生成CMake相关文件，这里需要指定构建版本为Debug版本，即在参数中指明-DCMAKE_BUILD_TYPE=Debug:

设置CMake参数为Debug构建模式

之后项目会生成一个main.cpp和一个CMakeLists.txt文件：

新项目文件

在CMakeLists.txt文件中增加如下配置，告知检查编译器是否支持C++ 11。

include(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
CHECK_CXX_COMPILER_FLAG("-std=c++0x" COMPILER_SUPPORTS_CXX0X)
if(COMPILER_SUPPORTS_CXX11)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
elseif(COMPILER_SUPPORTS_CXX0X)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
else()
    message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")
endif()

include(CheckCXXCompilerFlag)

CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)

CHECK_CXX_COMPILER_FLAG("-std=c++0x" COMPILER_SUPPORTS_CXX0X)

if(COMPILER_SUPPORTS_CXX11)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

elseif(COMPILER_SUPPORTS_CXX0X)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")

else()

message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")

endif()

之后可以对项目这一构建模式由默认的all重命名为Debug，重新对项目执行CMake操作。

重命名为Debug

重新执行CMake操作

完成上述操作之后，Debug对象的构建配置工作基本完成，可以通过如下代码检验是否能够支持C++ 11的语法：

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int main()
{
        vector<int> v = {5, 2, 1, 4, 3};
        sort(v.begin(), v.end());
        for(int i: v)
            cout << i << " ";
        cout << endl;

        return 0;

}

#include <iostream>

#include <vector>

#include <algorithm>

using namespace std;

int main()

{

vector<int> v = {5, 2, 1, 4, 3};

sort(v.begin(), v.end());

for(int i: v)

cout << i << " ";

cout << endl;

return 0;

}

编辑代码

之后可以尝试构建Debug对象（点击左下角锤子图标）：

构建Debug对象

尝试运行：

运行Debug对象

发现能够成功运行，那么至少配置Debug对象这一步就没有问题了。

5.调试

既然生成了Debug对象，那么调试功能自然不能少，尝试打一个断点：

断点调试

可以看出，在断点处查看局部变量等核心调试功能已经能够正常工作，单步、步入等功能也都可以正常工作。

6.发布程序

构建了Debug对象，那么作为生成产物的Release对象自然也不能少。

可以在添加一个构建模式：

添加Release构建模式

Debug对象与Release对象会通过CMake生成不同的配置，需要将二者放到不同的目录中：

配置Release构建目录

CMake参数上的区别在于需要指明-DCMAKE_BUILD_TYPE=Release:

配置CMake的Release参数

之后的构建运行同Debug。

构建运行Release对象

（CentOS下升级GCC参考了这里）。

以上。

CentOS6.5尝试lwan

发表回复

这些天看到了lwan，官网上号称作者历经三年打造的高性能轻量级可扩展Web Server，号称具备了低内存占用、最小化的系统调用次数、对静态文件根据大小智能的处理，预缓存目录信息以及7200行主体代码等特点，到今天（2014年12月26日）为止，Github已经收集到了2000+个star。

其中最吸引我的就是静态文件能达到18w qps，加上它较小的代码体积，于是想要试用一下。

阅读Github上的说明可知，这一软件需要用cmake，无碍，自己手上这台CentOS 6.5的机器上有，不过看到编译参数里面的-flto之后心里凉了半截，这东西CentOS 6.5上带的GCC 4.4.7不能编译啊……

好吧，简直就是噩耗，更换GCC实在不是什么省心的事儿，主要是手上测试机性能实在太差（Pentium双核+2G RAM+160GB HDD，10年的台式机……），估计只编译C/C++支持的话就得一个多小时了，无碍，那么就编译吧。

本次使用的是GCC 4.8.4，使用了日本镜像，速度较快。GCC还依赖三个库：

gmp (6.0.0)
mpfr (3.1.2)
mpc (1.0.2)

这三个库安装顺序可以为gmp -> mpfr -> mpc，mpc依赖前两者。

同时，需要通过yum安装glibc-devel以及glibc-devel.i686两个包。

在开始config之前，需要添加环境变量：

export LD_LIBRARY_PATH=/usr/local/lib

1 2	export LD_LIBRARY_PATH=/usr/local/lib

否则之前安装的gmp等三个库是没法用上的。

之后便是配置安装：

./configure --enable-checking=release \
            --enable-languages=c,c++ \
            --disable-multilib
make
make install

./configure --enable-checking=release \

--enable-languages=c,c++ \

--disable-multilib

make

make install

漫长的编译之后，会在先前的gcc目录（/user/local/gcc）生成，备份原有gcc（需要mv操作）之后通过可以考虑通过

mv /usr/local/bin/gcc /usr/local/bin/gcc-4.4.7
update-alternatives --install \
                    /usr/bin/gcc \
                    gcc \
                    /usr/local/bin/x86_64-unknown-linux-gnu-gcc-4.8.4 50

mv /usr/local/bin/gcc /usr/local/bin/gcc-4.4.7

update-alternatives --install \

/usr/bin/gcc \

gcc \

/usr/local/bin/x86_64-unknown-linux-gnu-gcc-4.8.4 50

切换版本。

GCC准备好了之后自然就要开始编译，编译时原本出现了一些对于比如luajit以及sqlite3的版本要求，但是作者今天在一个issue中提到似乎已经解决这一问题，这里就先略过，实际出现的话，根据出现问题的cmake提示，将软件依赖改为全路径即可。

编译时需要编译安装luajit以及通过yum安装mysql-devel。

在顶级目录编译完成之后，可以看到在顶级目录下的lwan目录中会生成一个名为lwan的二进制文件，将其拷贝到顶级目录，启动之后就可以体验lwan了。

lwan

关于端口的问题，可以通过修改顶级目录下的lwan.conf修改监听端口。

不过，最后要说的是其实自己的测试结果并不尽如人意，ab并发过万会引起lwan不响应其他请求，而Nginx则没有这类问题，还需要再次试验，确定问题的原因。

为yum安装的Nginx添加模块

发表回复

Nginx一般都是编译安装，不过它本身也提供了通过yum安装的方式，比如在CentOS 6.5中需要添加的/etc/yum.repos.d/nginx.repo文件内容为：

[nginx]
name=nginx repo  
baseurl=http://nginx.org/packages/centos/6/$basearch/  
gpgcheck=0  
enabled=1

[nginx]

name=nginx repo

baseurl=http://nginx.org/packages/centos/6/$basearch/

gpgcheck=0

enabled=1

之后就是常规的yum -y install nginx。

通过这一方式安装的Nginx已经可以通过系统服务的方式进行启动，相当便捷，但是很多有趣的第三方插件并没有能够加入，比如header-more-nginx-module，Nginx目前看来不像Tengine是可以后期动态添加模块的，所以解决的方案出了编译安装似乎没有其他的方式了。

不过Nginx编译只生成一个二进制文件，那么，如果获取yum安装的Nginx编译参数，之后使用同一版本的源代码进行编译，之后替换生成文件就可以了。

通过nginx -V就可以看到编译参数(1.6.2):

./configure --prefix=/etc/nginx \
            --sbin-path=/usr/sbin/nginx \
            --conf-path=/etc/nginx/nginx.conf \
            ...

./configure --prefix=/etc/nginx \

--sbin-path=/usr/sbin/nginx \

--conf-path=/etc/nginx/nginx.conf \

...

在获取同版本的nginx源码，同时也获得所需模块的源码后，在获得编译参数中加入--add-module=/path/to/module/source：

./configure --prefix=/etc/nginx \
            --sbin-path=/usr/sbin/nginx \
            --conf-path=/etc/nginx/nginx.conf \
            ...
            --add-module=../headers-more-nginx-module

./configure --prefix=/etc/nginx \

--sbin-path=/usr/sbin/nginx \

--conf-path=/etc/nginx/nginx.conf \

...

--add-module=../headers-more-nginx-module

之后进行make即可。

编译完成之后先备份位于/usr/sbin/中的nginx文件，之后关闭nginx服务，替换文件，重启服务，一个添加了所需模块的nginx应该就能正常工作了。

CI可能不应该使用持久连接Oracle数据库

发表回复

问题背景

看过CI框架用法应该会看到，在配置CI框架连接数据库时，默认会开启持久连接，即类似这样的配置$db['test']['pconnect'] = TRUE;，使用MySQL时会调用mysql_pconnect方法实现这一个功能，而oci8扩展恰巧也有类似的方法oci_pconnect:

oci_pconnect

方法的用处文档上说的很清楚：

oci_pconnect() 创建一个到 Oracle 服务器的持久连接并登录。持久连接会被缓冲并在请求之间重复使用，可以降低每个页面加载的消耗。

那么按道理来说这样的功能应该是会提升处理能力的，但是问题在于，持久连接会增加Oracle的进程数，一旦进程数耗尽，那么新的连接请求可能会被拒绝，反而会使得处理能力下降。

今天遇到了这样的一个问题，当双机各自开启1024个php-fpm进程时，使用sqlplus连接数据库被拒绝，同时各种操作都被拒绝执行。

所用的机器是两台阿里云的8核心16GB ECS服务器，Oracle数据库为11G R2，PHP版本为5.4，CI版本为2.2。

表现

首先是一次压测结束后，发现通过sqlplus连接不上Oracle数据库，即首先sqlplus /nolog之后使用conn命令无法连接成功，发现报错信息为：

max-proc-exceeded

居然没有可用的进程了！

那么目前需要做的就是释放这些进程，直接SHUTDOWN IMMEDIATE也该是最简单粗暴也能达到目的的方法，但是目前根本不能按照原先的sqlplus /nolog之后使用conn /as sysdba登录，解决的方式可以直接在shell中使用sqlplus / as sysdba即可完成登录。

分析

增加进程数

登录完成之后进行SHUTDOWN IMMEDIATE以及STARTUP操作，重启之后修改可用进程数：

alter system set processes=1000 scope=spfile;
alter system set sessions=1105 scope=spfile;
alter system set transactions=1206 scope=spfile;

alter system set processes=1000 scope=spfile;

alter system set sessions=1105 scope=spfile;

alter system set transactions=1206 scope=spfile;

关于这几个数值的关系，参考了这篇博文，博文中作者提到这三者可以按照如下关系配置：

processes=x
sessions=x*1.1+5
transactions=sessions*1.1

processes=x

sessions=x*1.1+5

transactions=sessions*1.1

使用spfile作为scope的参数原因是这几个参数并不能修改后立即生效，需要重启数据库之后才能生效。

修改完成后重启数据库，重新进行压测，ps -ef | grep oracle | wc -l发现进程数果然上来了，但是在压测结束后，发现再次出现了这一问题。那么这一问题并不单纯是进程不足的问题。

测试环境检查

Oracle进程数增加却被完全消耗，这个情况确实让人觉得奇怪。

检查CI的配置时，发现数据库配置文件中使用了pconnect属性，查阅oci_pconnect的文档，注意到如下一句话：

一个典型的 PHP 应用程序对于每个 Apache 子进程（或者 PHP FastCGI/CGI 进程）会有一个打开的持久连接到 Oracle 服务器

那么，目前一共有两台机器，每台机器开启了1024个php-fpm的进程，总计2048个，那么Oracle的进程数仅仅为1000个，自然是不够用的。

持久连接虽然减少了连接的成本，然后却使得没有进程可用，显然问题出在CI的持久连接上。

解决

解决的方式自然是关闭CI的持久连接配置，在设定$db['test']['pconnect'] = FALSE;之后，通过ab进行压力测试，在10000并发的情况下，所用的Oracle进程数长期维持在30个左右，基本上解决了这一问题。

结论

CI在使用持久连接时，可能需要考虑Oracle的可用进程数（设为X）以及php-fpm的个数（设为Y）之间的关系，当X>Y时，个人认为是可以考虑使用持久连接的。

否则，个人认为可以牺牲一部分性能来建立连接，使得Oracle维持有足够的可用进程数。