Mosquito的优化——其他优化(九)
2015-06-08 16:03
239 查看
本文由逍遥子撰写,转发请标注原址:
http://blog.csdn.net/houjixin/article/details/46413941
或
http://houjixin.blog.163.com/blog/static/356284102015584617535/
9.1、空闲空间管理机制优化
Mosquito原始版本程序中,有新的连接进来时,需要扫描整个context,查找一个空闲的位置以存放新连接产生的context,如果找不到空闲位置,则使用realloc再扩充一个context的位置。这种操作方式有两点非常低效:
1) 扫描context,每次有新连接进来的时候都要扫描context数组以查找一个空闲的context位置;
2) 当前context数组中不没有空闲的contxt时,只用realloc扩充1个位置;
针对上述两个造成低效的原因,将采用以下两种对应的方式进行优化:
1) 针对全扫描context数组的问题,将增加一个动态数组,用以保存当前所有空闲context的索引,当有新连接进来时直接从该动态数组中获取,而不需要每次都扫描全部的context数组;
2) 针对realloc只扩充一个context位置的问题,修改为每次context空间不够用时,将调用realloc申请一批(例如1000个)context的位置,然后将这些空闲位置的索引放入动态数组中。
9.2、消息发送机制优化
9.2.1 优化原因
Mosquitto原始版本的消息发送机制中将消息的接收和转发分开处理,其顺序为:
1) 在mosquitto_main_loop函数中根据poll返回的结果,如果一个就绪的socket是向某个主题发送消息,则搜索所有的订阅树,查找订阅了该主题的所有的订阅列表,并将该消息挂到订阅列表中每个context的消息队列中,此时,消息并未发送到订阅者。
2) 在函数mosquitto_main_loop中集中扫描所有的context并发送消息:如果其消息队列不空,则将消息队列中的消息发送出去。
这种消息发送机制的优点是逻辑清晰,但其效率非常低,因为每次消息发送时都需要扫描所有的context,才能确定哪些context有消息发送,哪些没有。
9.2.2 优化方法
针对mosquitto消息发送机制中需要全扫描所有context造成的低效问题,本次优化将增加一个hash表,该hash表将保存所有带消息的context,在消息发送时只扫描这个hash中的context即可,而不需要扫描全部的context,进而提升系统的运行效率,具体操作为:
1) 定义一个hash表,该表中每个结构包括一个socket和一个该socket对应的context,此表用于存放所有消息队列不空的context。
2) 将消息队列不空的context放入hash表,此过程在对epoll返回结果的处理中完成。该过程像poll一样,需要先搜索订阅树,查询订阅了该主题的所有订阅列表,并将消息挂到订阅列表的每个context中,如果该context未再hash表中,则将其加入hash表。
3) 发送消息,遍历hash表,将hash表中context的消息发送出去。
原来的mosquitto程序中,当有消息发送时,需要查询订阅树,找到对应主题的订阅列表,然后将消息挂到订阅列表中的每个context中,当客户端数量非常大时,每次发送消息查询订阅树都会花费一定时间,造成资源的严重浪费。
针对上述消息发送机制的问题,采用hash表存储topic到订阅列表的映射,在消息发送时只需要根据topic查找hash表,不需查找订阅树,从而减少系统资源的消耗。
http://blog.csdn.net/houjixin/article/details/46413941
或
http://houjixin.blog.163.com/blog/static/356284102015584617535/
9.1、空闲空间管理机制优化
Mosquito原始版本程序中,有新的连接进来时,需要扫描整个context,查找一个空闲的位置以存放新连接产生的context,如果找不到空闲位置,则使用realloc再扩充一个context的位置。这种操作方式有两点非常低效:
1) 扫描context,每次有新连接进来的时候都要扫描context数组以查找一个空闲的context位置;
2) 当前context数组中不没有空闲的contxt时,只用realloc扩充1个位置;
针对上述两个造成低效的原因,将采用以下两种对应的方式进行优化:
1) 针对全扫描context数组的问题,将增加一个动态数组,用以保存当前所有空闲context的索引,当有新连接进来时直接从该动态数组中获取,而不需要每次都扫描全部的context数组;
2) 针对realloc只扩充一个context位置的问题,修改为每次context空间不够用时,将调用realloc申请一批(例如1000个)context的位置,然后将这些空闲位置的索引放入动态数组中。
9.2、消息发送机制优化
9.2.1 优化原因
Mosquitto原始版本的消息发送机制中将消息的接收和转发分开处理,其顺序为:
1) 在mosquitto_main_loop函数中根据poll返回的结果,如果一个就绪的socket是向某个主题发送消息,则搜索所有的订阅树,查找订阅了该主题的所有的订阅列表,并将该消息挂到订阅列表中每个context的消息队列中,此时,消息并未发送到订阅者。
2) 在函数mosquitto_main_loop中集中扫描所有的context并发送消息:如果其消息队列不空,则将消息队列中的消息发送出去。
这种消息发送机制的优点是逻辑清晰,但其效率非常低,因为每次消息发送时都需要扫描所有的context,才能确定哪些context有消息发送,哪些没有。
9.2.2 优化方法
针对mosquitto消息发送机制中需要全扫描所有context造成的低效问题,本次优化将增加一个hash表,该hash表将保存所有带消息的context,在消息发送时只扫描这个hash中的context即可,而不需要扫描全部的context,进而提升系统的运行效率,具体操作为:
1) 定义一个hash表,该表中每个结构包括一个socket和一个该socket对应的context,此表用于存放所有消息队列不空的context。
2) 将消息队列不空的context放入hash表,此过程在对epoll返回结果的处理中完成。该过程像poll一样,需要先搜索订阅树,查询订阅了该主题的所有订阅列表,并将消息挂到订阅列表的每个context中,如果该context未再hash表中,则将其加入hash表。
3) 发送消息,遍历hash表,将hash表中context的消息发送出去。
原来的mosquitto程序中,当有消息发送时,需要查询订阅树,找到对应主题的订阅列表,然后将消息挂到订阅列表中的每个context中,当客户端数量非常大时,每次发送消息查询订阅树都会花费一定时间,造成资源的严重浪费。
针对上述消息发送机制的问题,采用hash表存储topic到订阅列表的映射,在消息发送时只需要根据topic查找hash表,不需查找订阅树,从而减少系统资源的消耗。
相关文章推荐
- Mosquito的优化——订阅树优化(八)
- Mosquito的优化——epoll优化(七)
- UEditor用法
- iOS: UIWindow in iOS
- GUI菜单练习
- quintic蓝牙芯片NVDS方法读写flash
- UIPopoverController的使用
- BAE Flask UEditor 使用七牛云
- HDU 1297 Children’s Queue(含整型大数模板)
- easyui中combobox的值改变onchang事件
- Unique Path
- 第五章:druid.io的应用场景
- easyui datagrid 中序列化后的日期格式化
- EasyUITreeGridMasterFile(EasyUITree大数据量一次性加载)
- Failed to issue method call: Unit mysql.service failed to load: No such file or directory解决的方式
- EasyUITreeMasterFile(EasyUITree大数据量一次性加载)
- Android自动化测试(UiAutomator)简要介绍 完整版本
- 百度ueditor编辑器插件开发之对话框-移动微模板插件
- Handling Technical Questions
- Android 使alertDialog.builder不会点击外面和按返回键消失