国内 PHP Composer 镜像列表

镜像列表

国内也很多开发者使用 Composer,但由于不可控因素,官方的服务器常常连接不上。所以这里收集了一下国内镜像列表。(先后次序会不定期调整)

镜像名

地址

赞助商

更新频率

备注

阿里云 Composer 镜像

https://mirrors.aliyun.com/composer/

阿里云

96 秒

推荐

腾讯云 Composer 镜像

https://mirrors.cloud.tencent.com/composer/

腾讯云

24 小时

PHP 国内 Composer 镜像

https://packagist.phpcomposer.com

仁润股份

24 小时

不稳定

华为云 Composer 镜像

https://repo.huaweicloud.com/repository/php/

华为云

未知

未知

php.cnpkg.org Composer 镜像

https://php.cnpkg.org

安畅网络

60 秒

配置镜像

全局配置镜像,以下为阿里云镜像配置命令,其它镜像可以参考以下命令。

composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/

php sqlite Connect Error: could not find driver

问题现象:

连接sqlite数据库,报错:Connect Error: could not find driver

产生原因:
1. 未加载pdo_sqlite
2. pdo_sqlite编译时configure未加with-pdo-sqlite参数

解决办法:

make clean

/alidata/server/php56/bin/phpize

./configure –with-php-config=/alidata/server/php56/bin/php-config –with-pdo-sqlite=/usr/bin/sqlite3

make && make install

vi /alidata/server/php56/etc/php.ini

/etc/init.d/php56-fpm restart

 

CentOS6.5 升级python2.6到2.7

先查看python版本
1、命令行输入python(如果python版本是2.7以上则跳过下面步骤)

升级python2.6–》python2.7以上版本

使用yum安装wget工具(存在则跳过)
yum install wget
将下载文件统一下载到home目录下
cd /home
下载和编译python2.7.5
下载时候可以自己到官网找自己想要的2.7以上版本官网地址:www.python.org/ftp/python
wget https://www.python.org/ftp/python/2.7.5/Python-2.7.5.tgz
解压缩文件
tar -zxvf Python-2.7.5.tgz (z是压缩格式,x为解压,v为显示过程,f指定备份文件)
进入解压后的文件
cd Python-2.7.5
检测是否有编译环境如gcc,配置安装路径,装在Python27目录下
./configure –prefix=/usr/local/Python27
在这里可能会报错没有编译环境
安装编译集成包
yum groupinstall “Development tools”
重新检查,和设置安装路径
./configure –prefix=/usr/local/Python27
make编译源文件
make

安装编译后的文件
make install
安装完成,python就会被安装到/usr/local/Python27目录下面的,然后我们替换系统自带的python2.6
先备份原版python
mv /usr/bin/python /usr/bin/python.bak
建立python2.7.5指向系统/usr/bin/的软连接(也就想当与windows的快捷方式)让系统使用新版的python
ln -s /usr/local/Python27/bin/python2.7 /usr/bin/python
到这里我们输入python就会在命令行显示我们新版的python2.7.5

但安装完后我们python2.7.5的模块还是空了,连setuptools工具都没有,pip也没有,我们yum安装功能也用不了
先解决yum问题,输入下面命令查看旧版python的全名应该会有一个python2.6
ls /usr/bin |grep python
编辑yum的脚本文件
vi /usr/bin/yum
把文件头部的#!/usr/bin/python改成#!/usr/bin/python2.6就是把旧版本python作为yum的执行环境,保存退出后yum安装即可正常运行。
setuptools模块安装到新版python2.7目录lib/site-packages/下
下载setuptools官网地址:https://pypi.python.org/pypi/setuptools
好像只有setuptools-38.6.0-py2.py3-none-any.whl (md5)和setuptools-38.6.0.zip (md5)两种包
官方推荐使用.whl包,但还不知道怎么安装,
直接下载zip包(2018年3月16号下载)
cd /home
wget https://pypi.python.org/packages/95/b9/7c61dcfa6953271f567a8db96f110cd8cf75e13a84c1d293649d584d2d39/setuptools-38.6.0.zip
解压zip包
unzip setuptools-38.6.0.zip
进入解压目录
cd setuptools-38.6.0
使用新版本的python安装
python setup.py install
在这里会报错,Compression requires the (missing) zlib module。缺少zlib模块
先安装缺少的模块
yum install zlib
yum install zlib-devel
将python2.7.5重新进行编译安装
cd /home/Python-2.7.5
编译,如果有报错,先跳过,直接下一步
make
安装
make install
进入到setuptools-38.6.0目录
cd /home/setuptools-38.6.0
再次安装,应该不会再报错了
python setup.py install
pip模块的安装
同上,官网地址https://pypi.python.org/pypi/pip ,下载压缩包
wget https://pypi.python.org/packages/11/b6/abcb525026a4be042b486df43905d6893fb04f05aac21c32c638e939e447/pip-9.0.1.tar.gz
tar -zxvf pip-9.0.1.tar.gz
cd pip-9.0.1
由于pip安装包依赖于setuptools模块,所以可以直接安装
python setup.py install

到这里,就完成的版本的基本升级。
后面就可以通过pip进行软件安装
2、pip版本的升级,由于替换的新版本python,安装pip可能不是最新版,先进行pip的升级
pip install –upgrade pip

接下来可以测试下pip是否更新成功

查看pip版本

pip –version

MySQL CPU跑满

原文链接:https://www.cnblogs.com/wyy123/p/9258513.html

用户在使用 MySQL 实例时,会遇到 CPU 使用率过高甚至达到 100% 的情况。本文将介绍造成该状况的常见原因以及解决方法,并通过 CPU 使用率为 100% 的典型场景,来分析引起该状况的原因及其相应的解决方案。

常见原因

系统执行应用提交查询(包括数据修改操作)时需要大量的逻辑读(逻辑 IO,执行查询所需访问的表的数据行数),所以系统需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。

说明:大量行锁冲突、行锁等待或后台任务也有可能会导致实例的 CPU 使用率过高,但这些情况出现的概率非常低,本文不做讨论。

本文通过一个简化的模型来说明系统资源、语句执行成本以及 QPS(Query Per Second 每秒执行的查询数)之间的关系:

  • 条件:应用模型恒定(应用没有修改)。
  • avg_lgc_io:执行每条查询需要的平均逻辑 IO。
  • total_lgc_io:实例的 CPU 资源在单位时间内能够处理的逻辑 IO 总量。
  • 关系公式:total_lgc_io = avg_lgc_io x QPS -- 单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量

解决方法

数据管理(DMS)工具提供了几种辅助排查并解决实例性能问题的功能,主要有:

  • 实例诊断报告
  • SQL 窗口提供的查询优化建议和查看执行计划
  • 实例会话

其中,实例诊断报告是排查和解决 MySQL 实例性能问题的最佳工具。无论何种原因导致的性能问题,建议您首先参考下实例诊断报告,尤其是诊断报告中的 SQL 优化、会话列表和慢 SQL 汇总分。

另外,如果您需要阿里云的技术支持来解决 CPU 使用率高的状况,请参见 https://market.aliyun.com/store/1682301.html

避免出现 CPU 使用率达到 100% 的一般原则

  • 设置 CPU 使用率告警,实例 CPU 使用率保证一定的冗余度。
  • 应用设计和开发过程中,要考虑查询的优化,遵守 MySQL 优化的一般优化原则,降低查询的逻辑 IO,提高应用可扩展性。
  • 新功能、新模块上线前,要使用生产环境数据进行压力测试(可以考虑使用阿里云 PTS 压力测试工具)。
  • 新功能、新模块上线前,建议使用生产环境数据进行回归测试。
  • 建议经常关注和使用 DMS 中的诊断报告。

    注意:关于如何访问 DMS 中的诊断报告,请参见 RDS 如何访问诊断报告

典型示例

以 CPU 使用率为 100% 的典型场景为例,本文介绍了两个引起该状况的原因及其解决方案,即应用负载(QPS)高和查询执行成本(查询访问表数据行数 avg_lgc_io)高。其中,由于查询执行成本高(查询访问表数据行数多)而导致实例 CPU 使用率高是 MySQL 非常常见的问题。

应用负载(QPS)高

现象描述

  • 特征:实例的 QPS(每秒执行的查询次数)高,查询比较简单、执行效率高、优化余地小。
  • 表现:没有出现慢查询(或者慢查询不是主要原因),且 QPS 和 CPU 使用率曲线变化吻合。
  • 常见场景:该状况常见于应用优化过的在线事务交易系统(例如订单系统)、高读取率的热门 Web 网站应用、第三方压力工具测试(例如 Sysbench)等。

解决方案

对于由应用负载高导致的 CPU 使用率高的状况,使用 SQL 查询进行优化的余地不大,建议您从应用架构、实例规格等方面来解决,例如:

  • 升级实例规格,增加 CPU 资源。
  • 增加只读实例,将对数据一致性不敏感的查询(比如商品种类查询、列车车次查询)转移到只读实例上,分担主实例压力。
  • 使用阿里云 DRDS 产品,自动进行分库分表,将查询压力分担到多个 RDS 实例上。
  • 使用阿里云 Memcache 或者云 Redis 产品,尽量从缓存中获取常用的查询结果,减轻 RDS 实例的压力。
  • 对于查询数据比较静态、查询重复度高、查询结果集小于 1 MB 的应用,考虑开启查询缓存(Query Cache)。

    注意:能否从开启查询缓存(Query Cache)中获益需要经过测试,具体设置请参见 RDS for MySQL 查询缓存(Query Cache)的设置和使用

  • 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。
  • 尽量优化查询,减少查询的执行成本(逻辑 IO,执行需要访问的表数据行数),提高应用可扩展性。

查询执行成本(查询访问表数据行数 avg_lgc_io)高

现象描述

  • 特征:实例的 QPS(每秒执行的查询次数)不高;查询执行效率低、执行时需要扫描大量表中数据、优化余地大。
  • 表现:存在慢查询,QPS 和 CPU 使用率曲线变化不吻合。
  • 原因分析:由于查询执行效率低,为获得预期的结果即需要访问大量的数据(平均逻辑 IO高),在 QPS 并不高的情况下(例如网站访问量不大),就会导致实例的 CPU 使用率高。

解决方案

解决该状况的原则是:定位效率低的查询、优化查询的执行效率、降低查询执行的成本。

操作步骤
  1. 通过如下方式定位效率低的查询:
    • 通过 show processlist; 或 show full processlist; 命令查看当前执行的查询,如下图所示:查看当前执行的查询

      对于查询时间长、运行状态(State 列)是“Sending data”、“Copying to tmp table”、“Copying to tmp table on disk”、“Sorting result”、“Using filesort”等都可能是有性能问题的查询(SQL)。

      注意:

      • 若在 QPS 高导致 CPU 使用率高的场景中,查询执行时间通常比较短,show processlist; 命令或实例会话中可能会不容易捕捉到当前执行的查询。您可以通过执行如下命令进行查询:
        1. explain select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on >= 2015-01-01 and a.detail = b.detail
      • 您可以通过执行类似 kill 101031643; 的命令来终止长时间执行的会话,终止会话请参见 RDS for MySQL 如何终止会话。关于长时间执行会话的管理,请参见 RDS for MySQL 管理长时间运行查询
    • 通过 DMS 查看当前执行的查询,查询步骤如下:
      1. 在 DMS 控制台上登录数据库
      2. 选择性能 > 实例会话,显示结果如下图所示:DMS 查看执行的查询

        从上图可以看出,有 10 个会话在执行下面这个查询:

        1. select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on>= '2015-01-01' and a.detail= b.detail;
      3. 单击 SQL 列中的查询文本,即可显示完整的查询和其执行计划,如下图所示:查询详情

        从上图可以看出,在该查询的执行计划中,系统对两张约为 30 万行的数据表执行了全表扫描。由于两张表是联接操作,这个查询的执行成本(逻辑 IO)约为 298267 x 298839 = 89,133,812,013(大概 900 亿),所以查询会执行相当长的时间并且多个会话会导致实例 CPU 使用率达到 100%(对于同样规格的实例,如果是优化良好的查询,QPS 可以达到 21000;而当前 QPS 仅为 5)。

  2. 得到需要优化的查询后,可以通过如下任意一种方式来获取查询的优化建议:
    • 通过 DMS 的优化查询获取:

      注意:对于 QPS 高和查询效率低的混合模式导致的 CPU 使用率高的问题,建议使用优化查询获取优化建议。

      1. 在 DMS 控制台上登录数据库
      2. 选择 SQL 操作 > SQL 窗口。
      3. 单击优化,即可得到优化建议,如下图所示:优化查询
    • 通过 DMS 控制台上的诊断报告获取:

      说明:诊断报告同样适用于排查历史实例 CPU 使用率高的问题。

      1. 在 DMS 控制台上登录数据库
      2. 选择性能 > 诊断报告。
      3. 单击发起诊断,即可创建一个针对当前实例运行情况的报告,如下图所示:诊断报告
      4. 单击查看报告,查看优化建议。

        注意:对于 CPU 使用率高的问题,建议关注诊断报告的 SQL 优化、会话列表和慢 SQL 汇总部分。

  3. 根据优化建议,添加索引,查询执行成本就会大幅减少(如下图所示,从 900 亿行减小到 30 万行,查询成本降低 30 万倍),实例 CPU 使用率 100% 的问题解决。优化结果

.NET MVC OutputCache

Web.config

<system.web>
<!–页面缓存–>
<caching>
<outputCacheSettings>
<outputCacheProfiles>
<!–缓存5分钟–>
<add name=”indexindex” duration=”300″ varyByParam=”*” location=”Any”/>
</outputCacheProfiles>
</outputCacheSettings>
</caching>
</system.web>

 

Controller

public class IndexController : Controller
    {
        [OutputCache(CacheProfile = "indexindex")]
        // GET: Home
        public string Index()
        {
            return DateTime.Now.ToString();
        }
    }

curl php file_get_contents 400 bad request

开始用PHP的file_get_contents请求,返回400 Bad Request,但是用浏览器或PostMan访问正常。

然后尝试用PHP的curl函数,一样的错误。

修改php.ini的user-agent或者给curl添加user-agent的header,一样的错误。

服务器直接执行curl命令,一样的错误。

经过一番研究,终于找到原因。

解决方案:url中的空格及加号需要替换为%20,执行成功。

str_replace(array(‘ ‘, ‘+’), ‘%20’, $param)

Apache通过htaccess添加权限验证

参考文章:http://www.htaccesstools.com/articles/password-protection/

With .htaccess it is very easy to password protect a folder or directory. The method is called htaccess password protection or htaccess authentication, and works by uploading two files called .htaccess and .htpasswd in the directory you want to password protect. The htaccess file should contain the following:

AuthType Basic
AuthName "Password Protected Area"
AuthUserFile /path/to/.htpasswd
Require valid-user

You only need to change “/path/to/.htpasswd” with the full path to your .htpasswd. Take a look at my article on how to find the full path using PHP. Next you need to upload the .htpasswd file which contains the username and password to enter the password protected folder. The .htpasswd file should contain:

test:dGRkPurkuWmW2

The above code will allow the user “test” to access the password proteced area with the password “test”. The text “dGRkPurkuWmW2” is a encrypted version of the password. You will need to use a htpasswd generator to create another password. Each line in the .htpasswd file contains a username and password combination, so feel free to add as many combinations as you like.
The automatic way – Use the generator
You can also just use the htaccess authentication generator to create a htaccess file for password protection.

React Native webview中video播放MP4格式视频只有音频

参考文章:https://blog.csdn.net/shaobo8910/article/details/81121965?utm_source=blogxgwz8

昨天遇到了这样一个问题,我打算使用HTML5的video标签简单的在网页上插入一个MP4视频,类似这样

<video preload=”none” controls>
<source src=”video.mp4″ type=”video/mp4″>
</video>
但是在网页中我点击播放的时候,却发现只有声音而没有图像。不过我用电脑中的视频播放器播放这段视频还是可以看到图像的。那么问题来了,这个锅谁来背?

问题出在哪

经过一些搜索得知,其实根本的问题是虽然大家都是.mp4后缀的文件,但是编码方式不同,而video标签的标准是用H.264方式编码视频的MP4文件(当然video标签还可以播放WebM和OGG格式的文件,这里就不多说了),而我之前使用的视频文件是Xvid编码的MP4文件,所以只能播放出音频而不能看到图像

解决方法

既然知道了问题出在哪,接下来就要想办法把我现有的视频文件转码成H.264编码的文件。
我使用的是Mac, 而且之前并没有装过什么视频转码的应用,搜索了一下发现Mac自带一个功能叫“编码所选视频文件”,我尝试着使用了一下。发现然并卵,生成的文件就像我在浏览器中播放的一样,只有声音没有图像,大概这个功能更适合吧其他格式的文件转换成MP4吧。
经过进一步搜索,发现了ffmpeg这个神器,使用这个命令行的工具,最终完成了视频编码的转换,下面详细介绍一下转换的方法

安装并使用 ffmpeg

我使用的是Mac,并且安装了homebrew,所以可以直接通过homebrew安装ffmpeg

brew install ffmpeg
其实ffmpeg的指令有很多,想要详细了解可以参见ffmpeg参数中文详细解释,这里我只需要把一个其他编码格式的MP4文件转换成H.264编码的MP4文件,具体指令如下

ffmpeg -i input.mp4 -vcodec h264 output.mp4
自行替换input和output文件名就可以了,其实这里input文件还可以是其他格式的视频文件,ffmpeg可以自动识别转换的方式,非常便利!
经过上述转换,使用输出的文件在Chrome上播放就没有问题了

MySQL的ibdata1文件占用过大瘦身

参考文章:https://blog.csdn.net/qq_32448349/article/details/82965878

处理MySQL的ibdata1文件过大问题

本人在对数据库进行大量的数据插入和删除的时候,发现ibdata1的占了将近一个T

ibdata1文件是什么?

ibdata1是一个用来构建innodb系统表空间的文件,这个文件包含了innodb表的元数据、撤销记录、修改buffer和双写buffer。如果file-per-table选项打开的话,该文件则不一定包含所有表的数据。当innodb_file_per_table选项打开的话,新创建表的数据和索引则不会存在系统表空间中,而是存放在各自表的.ibd文件中.

显然这个文件会越来越大,innodb_autoextend_increment选项则指定了该文件每次自动增长的步进,默认是8M.

是什么原因导致ibdata1文件会越来越大?

ibdata1存放数据,索引和缓存等,是MYSQL的最主要的数据。所以随着数据库越来越大,表也会越大,这个无法避免的。如果时间长了,越来越大,我们在处理日志和空间的时候就不是那么方便了,就不知从何入手了。接下来我们就要处理下这样的情况,分库存储数据。

该如何处理呢?

首先我们把数据库文件备份下来,然后直接删除ibdata文件(为了保险起见最好先全备一次,做到数据安全和完整),然后再重新导入数据库文件即可!

具体操作步骤如下(截图并不完整,但是首先要弄懂大概情况和原理):

第一种方法:

1、停止业务,备份一次全库

mysqldump -uroot -ppassword –all-databases  > all_mysql.sql
2、备份完成,停止数据库

systemctl stop mariadb 或者 service mysqld stop
3、修改配置文件

在[mysqld]下增加下面配置 innodb_file_per_table=1 验证配置是否生效,可以重启mysql后,执行 #service mysqld restart
4、验证

mysql -uroot -ppassword mysql

show variables like ‘%per_table%’;

+———————–+——-+

| Variable_name | Value |

+———————–+——-+

| innodb_file_per_table | ON |

+———————–+——-+

1 row in set (0.00 sec)

innodb_file_per_table的状态变为ON

5、删除ibdata1文件和日志

rm -rf ibdata1

rm -rf ib_logfile*

6、还原数据库

mysql -uuser -ppassword

source all_mysql.sql

数据文件单独存放(共享表空间改为每个表独立的表空间文件)。

第二种方法:

把数据库的表引擎为InnoDB 的数据表转为MyIsam 后,删除ibdata1,按上面方法修改成独立的表空间,在把改成MyIsam引擎的表改为InnoDB,这个就要衡量那种方法的时间耗时最短,两者取其优。数据的表和库很多的通常不建议这么做,耗时间。

CentOS + Apache2.4 + PHP5.6 FPM报503错误

Service Unavailable 503错误,很可能的原因是服务器过载。

错误提示:

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

服务器使用Apache2.4,fpm方式加载PHP,因此排查解决过程如下。

1. 查看PHP-FPM日志
#tail -f /alidata/server/php56/var/log/php-fpm.log
WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

2. 修改PHP-FPM配置
#vi /alidata/server/php56/etc/php-fpm.conf
pm.max_children = 5
​修改为
pm.max_children = 100

计算依据参考:https://blog.csdn.net/solmyr_biti/article/details/53955141
pm.max_children = Total RAM dedicated to the web server / Max child process size – in my case it was 85MB
The server has 8GB of RAM, so:
pm.max_children = 6144MB / 85MB = 72

JS关闭网页window.close(兼容各类浏览器,包括微信浏览器)

function closePage()

{

var userAgent = navigator.userAgent;

if (userAgent.indexOf(“Firefox”) != -1 || userAgent.indexOf(“Chrome”) !=-1) {// Firefox或Chrome中关闭

  window.location.href = “about:blank”;

} else {

  window.opener = null;

  window.open(“”, “_self”);

  window.close();

}

if (WeixinJSBridge) {// 微信中关闭

WeixinJSBridge.call(‘closeWindow’);

}

}