加载中
01/10 11:35
发表了博客评论:
可以关注官方公众号,回复关键词即可获取
2022/09/16 17:38
发表了博客评论:
模拟爬取可能就需要考验风控的功力了
2022/09/16 17:29
发表了博客评论:
模型加载部分的一些优化: (1) 模型map由C++ native加载,耗时降低至原先Java方式的20%,C++占用内存相比Java也更少; (2) 原先单服务实例会加载所有模型,近期又做了改造优化,改成类似redis cluster模式,单服务实例只加载部分模型,服务粒度更细。
2022/09/16 17:29
发表了博客评论:
还好,服务启动与运行都比较稳定。 缓存部分基于事件驱动回源加载,模型加载部分我们做了很多优化,另外我们服务是高配资源,整体控制比较稳定。
2022/09/14 09:13
发表了博客评论:
如果公共部分很稳定,npm包发布了一次可能再也不用更新了。VAPD就是这样,现有的技术满足我们的业务需求,就不用过早优化了。 不过基于这个问题,我们也有技术方案,简单的说就是子应用设置一个
<div></div>,然后父框架拿到这个dom节点进行渲染公共部分, new Vue().$mount(子应用dom节点)。具体实现需要等待我们下篇文章了。
2022/08/26 14:12
发表了博客评论:
感谢提的宝贵意见。我们测试过java纯计算能力确实比c++要快的,但随着压力的增加,gc的频率也相应的增大,整体的吞吐量要比jni方式低一些的,或许我们还可以在gc上面再优化优化。
2022/08/26 14:11
发表了博客评论:
c++使用的内存确实不比java的少,但可以减轻java的GC成本。目前jvm分配的内存是很多的,计算的对象大多是大对象,频繁的进行计算,gc的频率也会变高,用jni的方式,gc的频率和耗时确实有明显的减少。
2022/08/26 14:11
发表了博客评论:
是的,目前的应用场景确实不是复杂的运算场景。用JNI技术能够在低成本的情况下解决当前性能瓶颈,后续会逐步进行一些优化,用cpp rpc方式也是列在了迭代计划中的。
2022/08/26 09:45
发表了博客评论:
javacpp在调研的时候也了解了一下,其底层也是使用JNI的原理。相比于JNI,开发方便,但是性能方面我们没有实际测试过。如果对此感兴趣,可以去了解一下javacpp,也推荐了解一下JNA。
2022/08/24 12:11
发表了博客评论:
用C++写一个服务,在调用上会有网络开销。若封装成一个JNI的SDK,其他业务使用的话会比较方便,并且也减少了网络开销~
2022/08/09 10:19
发表了博客评论:
图片上传后会有压缩,可以查看下公众号原图
2022/08/09 10:19
发表了博客评论:
是跨平台哈,内容已更正
2022/05/18 11:10
发表了博客评论:
升级到HDFS 2.x最新版,再升级到HDFS 3.x,需要升级两次,升级周期长。HDFS社区支持HDFS 2.x直接升级到HDFS 3.x,只需要升级一次,升级时间短。当然,如果升级时间允许的话,也可以升级到HDFS 2.x最新版,再升级到HDFS 3.x。
2022/01/11 09:59
发表了博客评论:
那么我们的补偿任务的数据筛选sql类似这样: select * from db{year}.tbl_order where status = 1。 那这样的话,由于year作为了分库键,定时任务执行的时候需要将分库键传进去,那如果是元旦的凌晨,定时任务传入的year是2022,那么db2021.t_order中的数据就会出扫漏。 所以一般跨年后的一段时间段需要进行一些特殊处理,定时任务需要分两批,分别去扫描上年度和新年度的数据。
2022/01/11 09:59
发表了博客评论:
你好~假定按照年度进行了分库,比如2021年的在db2021.tbl_order表中,2022年的在db2022.tbl_order表中。表中有个字段status=1表示需要扫描补偿的数据。
2022/01/11 09:57
发表了博客评论:
是的,读写分离不会增加主库的数量。
2022/01/11 09:46
发表了博客评论:
你好~时间只是一个可选维度,处理一些强时序型的数据比较合适。然而如文中云盘元数据的场景,每个用户随着时间的增长,数据量都越来越大,一个用户要获取自身的云端文件,那么就需要基于用户维度进行分库分表。
2021/11/26 14:13
发表了博客评论:
你说的这两种情况目前未尝试,不过可以分析下 第一种情况:只设置metaspace和增加Young区,不改变收集器,可以推算出这样调整后,Young GC的单次耗时会增加, Young GC的频率会下降,同时,Full GC单次耗时会下降,但是频率会增加,整体上对时间敏感的应用会有一些改善,但不会有大的飞跃。 第二种情况:我觉得从原理上是可行的,但由于当前调优的结果已经符合预期,所以并未求证
2021/11/09 14:17
发表了博客评论:
你好,鉴于目标服务的特点,PS/PO是不考虑的。关于变量的问题,文中除了两种收集器之前的对照,对CMS收集器也拆分了多个场景,控制每个场景的变量来实验,才决定用什么参数的。
2021/11/09 11:19
发表了博客评论:
某个接口99%情况下的耗时,相较于平均耗时,更具体有代表性。

没有更多内容

加载失败,请刷新页面

返回顶部
顶部