phalcon 框架执行流程图
phalcon 框架执行流程图
…
原解决PHP脚本pdo MySQL has gone away错误 pdo加ping功能
<?php
class NPDO {
private $pdo;
private $params;
public function __construct() {
$this->params = func_get_args();
$this->init();
}
public function __call($name, array $args) {
try {
return call_user_func_array(array($this->pdo, $name), $args);
} catch (PDOException $e) {
}
}
public function ping() {
… Centos7 yum安装php7.0可以改变yum源
1.如果之前已经安装我们先卸载一下
- yum remove php php-common
2.由于linux的yum源中的php不是最新版本，所以我们使用https://webtatic.com/的yum源来安装，可以直接参考https://webtatic.com/packages/php70/…
原关于PHP的回调函数及事件回调的用法
PHP的回调机制，是通过使用 call_user_func（call_user_func_array）实现的。回调函数可以很好地将一些功能从核心功能剥离开。
回调机制类似于一种通知机制，在异步编程中经常用到。 就是 我让你做一件事情，你做好了，通过我提供的接口通知我。
代码如下。…
关于实时推送系统的那点事
大家好，我是于小波，2011年加入魅族，现在在魅族移动互联网部门，主要负责服务端后台架构设计和开发工作。…
实时系统架构与实践
实时系统架构与实践
概要
分享基于 MQTT 协议的、面向移动互联网的 实时消息、实时统计、实时在线系统的架构设计；团队在云主机、部署自动化、监控自动化实践；团队在高性能分布式 Key/Value 存储的实践。 听众受益： 了解 MQTT 协议在移动互联网、智能设备上使用的优势， 了解大型实时系统的基本架构设计原理， 小团队如何利用云端资源快速实现、运营产品， 自动化 部署、监控 系统及实践方法， 高性能 Key/Value 系统的新设计理念
http://www.infoq.com/cn/presentations/framework-and-implementation-of-real-time-system…
erlang 虚机CPU 占用高排查
-问题起因
近期线上一组服务中，个别节点服务器CPU使用率很低，只有其他1/4。排除业务不均，曾怀疑是系统top统计错误，从 Erlang调度器的利用率调查 找到通过erlang:statistics(scheduler_wall_time) 查看服务器CPU低的机器调度器实际的CPU利用率很高接近100%，而其他机器都不到30%。
分析不同业务服务，发现只有在node 中进程数采用调度器CPU利用低这个问题。…
基于 erlang 的Ejabber 压力测试
1.测试环境
- 服务端：普通机*(I3 2核心4线程)/mem:16GB
- 客户端：普通机*(I3 2核心4线程)/mem:48GB（4台）
- 系统：sys:Centos 6 Erlang:OTP 18 Ejabberd 15
- 网络：内网千兆互联
分布式测试…
erlang高并发的优化
Ejabberd官网上Performance Tuning有一写关于优化的clue，这些参数可以在ejabberdctl.cfg里面修改
- Erlang Ports Limit: ERL_MAX_PORTS 建议使用，调的大一些
- Erlang consumes one port for every connection, either from a client or from another Jabber server. The option ERL_MAX_PORTS limits the number of concurrent connections and can be specified when starting ejabberd:
erl
Linux下高cpu解决方案（转载）
昨天搞定了一个十万火急的issue，客户抱怨产品升级后系统会变慢和CPU使用率相当高，客户脾气很大，声称不尽快解决这个问题就退货，弄得我们 R&D压力很大，解决这个issue的任务分给了我，客户是南非的一个公司，由于时差问题，我只好在家远程解决问题，晚上8点半用 gotomeeting远程到客户电脑查看我们的系统，折腾了四个多小时，终于在凌晨时reproduce了这个high CPU，赶紧抓Log，用wireshark抓包，用gcore,gstack,strace和top保存了系统的相关输出。在第2天分析了这些文件后， 找到了产品的bug，代码的作者分配了10K的缓冲区，并想当然认为10K足以够用，当然99%的情况下是够用的，但是在这1%的情况下出现了问题，缓冲 区不幸被写满了，然后程序进入了死循环，导致high CPU。找到了问题了，fix就很容易了，客户的脾气也缓和了，fix很快就可以deliver给客户。反思解决问题的过程，觉得这个分析过程具有可复用 性，值得总结一下。…
近期评论