标签归档:fuload

RSS feed of fuload

最后更新于 .

之前的文章已经提到了 django+fastcgi的运行并不如意(web.py+spawn-fcgi却正常很多……),所以特意抽时间研究了一下uwsgi,试了一下,运行的很好,也很快,哈哈。 所以笔者的所有之前用apache+django搭建的项目(如fuload等)都已经替换成了nginx+django+uwsgi。 一.安装uwsgi
  1. http://projects.unbit.it/uwsgi/wiki/WikiStart#Getit 下载最新版本的uwsg。
  2. 解压后,如果没有安装libxml2,又不想安装的话,那么编辑文件 buildconf/default.ini, 把
    xml_implementation = libxml2
    
    改成
    xml_implementation = false
    
  3. 执行编译
    python uwsgiconfig.py --build
    
  4. 执行安装
    python setup.py install
    
这样 ...

最后更新于 .

接着上一篇文章: 有限状态机的C++实现(1)-epoll状态机,我们今天来介绍更复杂和深入的部分。 为什么会在标题中提到bayonet这个开源项目呢?笔者本人一直想要写一套架构优美、功能完善的异步server框架,也看过很多朋友、同事实现的版本,虽然功能上基本能满足需求,但是架构上我却始终觉得是有瑕疵的,直到后来和同事讨论,发现可以让一个客户端请求的到来作为一个session,而之后的每一次与其他server的交互都可以看作是一次状态转化,才感觉架构比较合理了。 简单来说即,一个session从开始到介绍会经历两种状态机的变化:
  • 1.业务逻辑层面的状态变化,例如先验证登录态,再验证权限,再获取用户资料
  • 2.每一个与其他server交互的socket自身的状态变化,如recv、send、等,而socket的状态变化会触发逻辑层的状态变化。
按照这种思路,目前的代码开发已经完成了70%,即可以正常的进行一个session的开始和结束,主要还缺一些细节的代码,比如超时的检测及超时之后的处理,健全的统计之类。好了,我们来用vs看一下代码的整体类图(图压缩比较严重,请单击后查看):

1

每个类的用处已经在途中简单说明了,这里就不再赘述,我们重点来看一下用这个框架来实现一个逻辑server时需要做哪些事情。 svr2目录下的main.cpp即实现了一个最简单的server,我们按部分来看其实现: 1.逻辑层状态的定义
class CAppFsmLogic1 : public CAppFsmBase ...

最后更新于 .

2010年过去了,非常感谢在这一年里关注着vimer.cn的博友们,也希望新的一年里大家能够更多更好的分享和交流!~

借此机会,笔者在这里简单总结一下自博客创建以来的一些事件和文章,对新读者可以有一个清晰的索引,老读者也可以简单做一下回顾~

2009年10月
vimer.cn博客正式开通,这段时间主要以vim的入门介绍为主,并且由于工作关系,也会有一些C/C++相关的探讨.
推荐文章:


2009年11月
这段时间主要是一些vim正则查找替换之类的技巧。
推荐文章:

2009年12月
这段时间开始有较多的C/C++语言及linux下编程的一些经验分享 ...

最后更新于 .

fuload的前端页面的展示之前总是不能让我满意,尤其在日期选择控件这里,或者就是和chrome不兼容,或者就是页面乱掉之类的其他问题。 再试用了多个控件未果之后,突然想起来django的后台就有一个很漂亮的时间控件呀。 所以在网上搜了一下,果然已经有朋友尝试过了,链接如下: http://cnmsdn.com/html/201004/1270535813ID3307.html 我们先按照文中的方法一步步做: 现在forms.py中修改:
from django import forms
from comm_def import rtype_original_keys,rtype2attr
from django.contrib.admin import widgets

class SearchReportShowForm(forms.Form):
    reportid = forms.IntegerField(required=True,label='上报ID')
    begintime = forms.DateTimeField(required=True,label='时间',widget=widgets ...

最后更新于 .

一直以来,我都在考虑一个问题,怎么能保证在一个单机访问量上万的服务在上线之后一定是稳定的呢?测试,我们有单元测试,功能测试,但这是否够了呢?不够!一定尽量模拟正式环境的测试,否则一切都是没有办法保证的。 所以我写了fuload这个压力测试框架,并且把它开源,原因有几个:
  • 1.让所有人的做压力测试变得简单
  • 2.让尽量多的人,参与到开源项目里来
这个项目目前虽然已经能够正常的提供服务,但还需要尽量多的优化,所以很希望有朋友能够参加进来。另外,本博以后也会负责一些开源项目的开发和维护。一群素未蒙面的人一起完成一件有意义的事情,酷! 项目网址如下:http://code.google.com/p/fuload/ 详细的说明文档如下: 一.这个框架能做什么? 简单来说,fuload是为了给大型服务做压力测试或性能测试诞生的,你可以通过fuload来对你待上线或者已经上线的服务进行压力测试,并能通过详细的报表得出对你的服务的客观评价。 二.架构说明 整个框架实际包括两个部分:master和slave,master上运行用来统计的网站,slave上会调用用户自写的so并实现向master的上报. 上报的结果可以直接在master端查看,链接如下:http://{youhost}/report/show/(如图所示):

1

1

三 ...

最后更新于 .

这篇文章还是关于fuload项目的问题,由于压力测试的结果最后是要给出可视化统计曲线及饼图的,所以这里就涉及到数据上报时间,格式,以及绘制算法的问题。
饼图比较简单,我们这里主要看调用时间的曲线图。
我们采用自顶向下的方法来分析,先分别来看输入和输出。
前提


  • 有多台机器(称为从机),同时想远程机器上报,由远程机器(称为主机)统一绘制。


输入

  • 一段时间内(如5分钟):起始时间,结束时间,总的调用时间,调用次数,平均调用时间。


输出

  • 根据平均响应时间,绘制时间为横轴,调用时间为纵轴的走势曲线图。

这里主要有几个难点


  • 1.对于这“一段时间”来说,每台从机是不一样的,即可能A机器报了7点5分~7点10分的数据,而B机器报了7点7分到7点12分的数据,也可以理解为主机端接收到每台从机上报数据时间点是不统一的。要解决这个问题,我们可以通过对上报数据做分片的处理,简单来说,既然我们选择了5分钟上报一次,那么统计图的X轴一定是5分钟一个统计点,比如拿7点5分~7点10分这段时间来说,7点7分~7点12分的数据有3/5落在了这个时间段(具体计算可以更精确),另外有2/5落在了7点10分~7点15分,这样统计曲线就可以绘制出来了 ...