Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederddadaal.me
ddadaal.me RSS
Get the latest updates from ddadaal.me RSS directly as they happen.
Follow now 27 followers
Latest posts
Last updated 2 months ago
Node是并发性能的绊脚石吗？研究Node Web服务器的基准并发能力
2 months ago
问题发现 最近在一个项目中，我遇到了一个使用Node.js编写的请求转发服务的性能瓶颈问题。这个服务的主要工作看似非常简单：获取用户的请求，将请求体(body)转发到后端的服务器，然后将服务器的响应原样返回给客户端。 然而，在进行压力测试时，我们发现当并发请求达到约2000时，系统表现出了明显的性能问题： 大约6%的请求出现错误 服务器资源利用率极不平衡 - 只有一个CPU核心达到了100%利用率，而其他核心几乎处于闲置状态 大家都说Node.js的IO性能并不算差。这个现象引发了我的思考： 是什么限制了Node.js在这种场景下的性能表现？ 一个看似简单的请求转发工作，为何无法充分利用多核资源？ 带着这些疑问，我决定对Node.js代理服务的基准性能进行一次深入研究。我想了解在没有任何特殊优化的情况下，一个标准的Express服务究竟能够处理多少并发请求。这将帮助我确定问题是否出在Node.js本身的并发处理能力上，并在之后遇到类似性能问题或技术选项的时候，对Node本身所能达到的极限能力有个心理预期。 实验设计...
Node是并发性能的绊脚石吗？测试Express服务器的基准并发能力
2 months ago
问题发现 最近在一个项目中，我遇到了一个使用Node.js编写的请求转发服务的性能瓶颈问题。这个服务的主要工作看似非常简单：获取用户的请求，将请求体(body)转发到后端的服务器，然后将服务器的响应原样返回给客户端。 然而，在进行压力测试时，我们发现当并发请求达到约2000时，系统表现出了明显的性能问题： 大约6%的请求出现错误 服务器资源利用率极不平衡 - 只有一个CPU核心达到了100%利用率，而其他核心几乎处于闲置状态 大家都说Node.js的IO性能并不算差。这个现象引发了我的思考： 是什么限制了Node.js在这种场景下的性能表现？ 一个看似简单的请求转发工作，为何无法充分利用多核资源？ 带着这些疑问，我决定对Node.js代理服务的基准性能进行一次深入研究。我想了解在没有任何特殊优化的情况下，一个标准的Express服务究竟能够处理多少并发请求。这将帮助我确定问题是否出在Node.js本身的并发处理能力上，并在之后遇到类似性能问题或技术选项的时候，对Node本身所能达到的极限能力有个心理预期。 实验设计...
用大模型总结文章：效果绝佳！
3 months ago
Azure AI Language Service的结果太差了 去年我给我的文章增加了AI文章总结功能。在介绍此功能的文章，我提到当时这个功能是通过Azure AI Language Service Text Summarization的功能实现的。 当时我已经发现，这个功能在英文文章上效果还行，但是在中文文章上就基本不可用。 比如，上一篇文章2024年总结的总结结果是：...
用大模型总结文章：效果很好，但是玄学
3 months ago
Azure AI Language Service的结果太差了 去年我给我的文章增加了AI文章总结功能。在介绍此功能的文章，我提到当时这个功能是通过Azure AI Language Service Text Summarization的功能实现的。 当时我已经发现，这个功能在英文文章上效果还行，但是在中文文章上就基本不可用。 比如，上一篇文章2024年总结的总结结果是：...
2024年总结
4 months ago
最好的年龄该如何度过？通过深入体验现有的生活 毕业后的第一年，没有物质压力，有大把时间可以自由支配。这最好的年龄该怎样度过？ 我今年的答案：深入体验现有生活。 旅游，和朋友和家人刷新地图的边界 随着之前的朋友毕业、上班，有了更多时间，以及个人工作生活的稳定，今年的旅行数量可能大于之前26年来的总和，三个国家，国内十余个城市和景点。根据航旅纵横的数据，只算飞机，今年的飞行里程甚至超越了99.13%的用户。要是有规划地选择航司，现在应该能飞个银卡吧。 我不是一个非常喜欢旅游的人，如果只有一个人，外出旅游不会成为我的首要选择。正因为有了朋友和家人一起，我才能有机会和动力去打卡这些可能之前都没有听说过的地方。比旅游本身更重要的，是和朋友和家人在一起的这段经历。很感谢你们愿意花时间陪我去做我一个人不会去做的事情。 搬家，开启独居生活 和大多数人一样，上大学前和家人合住，上大学后和舍友合住，而在今年8月，随着合住的大学同学搬走，我终于租下了一个一室一厅的公寓，第一次开始独居生活。 我的“第一套房子”是一个公司附近的保租房公寓。好处很明显：离公司比较近（电动车10分钟），楼体和装修新，空间勉强够用，各个功能区分割比较现代和合理（甚至是三分离的卫生间），且也没有遇到太多质量问题。 但更重要的是，没有其他选择了！公司地处偏远，附近几乎全是老破小楼梯房，电梯房本来就寥寥无几，而离地铁和公司近的房子只有几栋10年前的动迁房，而实地看房的第一印象就是廉价的装修：本来就只是为了出租而进行的装修，在10年后更加显现出岁月的痕迹，租金却也没比保租房公寓便宜多少。 于是也不用犹豫了，很快定下合同，还没入住的时候我就迫不及待地购入了升降桌，在家人的帮助下，将这个可能会是待的时间最多的地方好好打造了一番，还正好蹭上手机号所在的运营商的活动，拉上了18块一个月500M的宽带，开始美美地独享这个小窝。 由于公寓是住宅标准，所以有正常的厨房和煤气。一个人住，也不用拘泥于吃饭的形式：想吃火锅却懒得买电火锅，也可以直接凑在灶台前吃。...
在西雅图，给生活换个环境
11 months ago
“洗洗班味” 上班之后的生活千篇一律：起床，上班，去食堂吃午饭，去游戏室睡觉，上班，下班，看视频玩游戏，睡觉。按朋友的话来说，这样的日子会让人“班味很重”。所以当在3月份第一次听说公司组织的Aspire Start Strong+活动的时候，我虽然不是那么一个喜欢旅游的人，但是还是仍然感觉非常激动，很珍惜这个机会，毕竟这个活动由公司出钱、不占用自己的假期、和全世界去年的校招生一起去美国参加，而因为有了这三点，活动具体是干什么的反而都不重要了，在全新的环境里给生活暂时换个节奏，按同事的话说，“洗洗班味”，是最重要的。于是开始火速走流程，给老板科普这个活动是干什么的、去北京办美签、订酒店，终于在上周成行。 体验另一个世界 这不是我第一次出国出境，但是确实是第一次在到美国，这个完全和国内、甚至东亚主流生活方式完全不一样的地方。 由于活动会场在市区，所以我们住在西雅图的市区（downtown）。这一个区域确实有大城市的感觉，高楼大厦鳞次栉比，由于西雅图并不平，有山，车道也普遍仅有双向四车道，第一次进市区以为回到了重庆的渝中。但是这个区域并不移居，人不多，有经典流浪汉，并且也比较危险，途中左边的麦当劳被称为“死亡麦当劳”，听说我们到达的前一天发生了枪击案，因此，第三天晚上被迫不得不在快天黑的时候出去时，我和舍友不得不加快脚步。并且，市区虽然有很多商场，但是实际上非常萧条，我们去的一个比较大的商场Pacific Place里面仅仅只有几个商店。 而在市区之外的地方，并不是国内郊区常见的农田或者工厂，而仍然是城市，只不过是一望无际的平房大house，大多数的中产生活在这里。这些地方不能叫西雅图的郊区，因为实际上是另一个小城市，各个城市有自己的downtown，甚至Apple Store和一些品牌的专卖店都只有这些小城市的购物中心才有。各个城市之间的交通，也主要以车为主。各个城市之间非常近，例如微软总部所在的Redmond和???雅图市区开车仅需30分钟，相当于同属主城区的闵行和人民广场之间的距离。所以，这次我深刻体验到了什么叫”没车就是没腿”。 由于我对我的驾驶技术并没有太大信心，加上市区开车成本极高，所以没有租车，所以我也只能在市区简单逛逛旅游景点，旅游景点之间的交通也是通过打车。这和国内所有资源都集中在市区的情况可谓大相径庭。 世界的不同同样也体现在社会的各个角落：和陌生人进入电梯也要打招呼，和其他人沟通时经常能看到幅度很大甚至有点夸张的表情和肢体动作，几乎每次打车遇到的司机都想和乘客聊天，甚至餐厅吃饭时，服务员的服务，结账时的流程也完全不同，于是在前一两天，干啥事都要做好出丑的准备。...
2022年总结
over 2 years ago
转折点 又是一个转折点，是2021年总结的最后一节小标题。不出意外的，2022年确实是一个转折点。 玩具项目开始“玩真的” 上半年，继续维持2021年下半年的状态，像是做个玩具一样，在一个人的宿舍没有压力地写着实验室的项目。 可是，像是被赶鸭子上架一样，五月份项目放到GitHub开源（仓库地址），在一个小会上做报告，六月份写了一篇论文投到HPC China会议上然后拿了满分评价和优秀论文提名，之后项目组多了好多学弟学妹、老师和同事。公开的demo集群（点击访问，用户名密码参考仓库README）上线了，潜在用户来找我们了：项目突然变得认真了。 GitHub动态 会议论文评分 飞书组织 从一个随便写着玩的小程序员到啥都管的“小老板”，带人给了我更大的压力。不同的人有不同的背景、不同的能力、不同的期望。应该把什么样的工作给谁做？我自己应该把事情做到什么程度？我应该提供什么样的支持？什???事情应该他自己思考？怎样高效地沟通？如何我的想法更高效、更准确地告诉其他人，如何让同事更好的告诉我他所想的？如何和一个有数年、甚至数十年工作经验的人合作？这些问题对不同的人都有不同的、且随时都在变化的答案。我的一切行为可能都会影响同事接下来的一段时间如何开展工作，一丁点没有考虑到的细节，一点工作需要的、但是没有写进文档的、而且我也没亲口告诉的知识点都可能让别人浪费数倍的时间。甚至，我连我需要什么样的人这样基础的问题，我都没法给出一个自信的回答。如何作为一个并没有实际工业界经验的小小研究生来说，我只能根据在课堂和网络上看到的以及短时间的实习中体验到的经验依葫芦画瓢，尝试建立一个尽可能高效的团队。目前看来还有很长的路要走。 meme 项目本身也有很长的路要走。项目复杂起来之后，CI/CD流水线、自动化测试、文档、协作工具、仓库管理、版本发布，甚至如何保证代码风格的一致性，这些繁琐的事情的重要性越来越高了。代码之外，用户究竟需要什么样的功能，如何让用户部署和使用系统更方便，什么样的需求该做和不该做，项目应该朝什么样的方向发展，虽然最终拍板的不全是我，但是这些问题都需要我的参与和讨论。这些问题都不是确定的问题，也没有一个固定的量化指标，但是对于项目来说，可能比写100个功能点更重要。...
2021年总结
over 3 years ago
暴风雨之前的宁静 站在2021的年尾回看这一年，发现这一年着实有点波澜不惊。 这一年中没什么非常关键的里程碑事件。没有2018年的各种比赛和活动充实我的简历（以至于现在还在吃当年的老本）；没有2019年决定保研，确定了未来三年的生活状态，以及实习，第一次进入梦想中的公司去工作；没有2020年的本科结束，告别至今对我最具意义的四年，以及研究生开学，迎接一段外表看上去光鲜、但是自己却不那么肯定的研究生生活。这一年发生的各种事件看上去都那么的日常，有时候日常地甚至连朋友圈都懒得发。 但是，可以遇见到，2022年将会是一个“腥风血雨”的一年。再次准备实习面试，再次暑期实习，参加秋招，确定出路，每个步骤都是一场不可避免的硬仗。用暴风雨之前的宁静来总结2021年实在是再合适不过了。 本年度的事件 项目和比赛 我一直认为，不被人使用的项目没有意义。所以，即使项目是大家都觉得没啥技术含量的CRUD，只要真的有人用，我仍然会接受并且愿意花心思和时间把它做好。所以上半年除了上课，很大一部分时间投入到了data-competition.pku.edu.cn的开发上了。这个项目之前写过文章详细介绍，我这里就不讲了。 5月份的时候参加中心主办的“新手友好”的CTF比赛，结果就会做娱乐题和web题，其他题一点思路都没有，说到底还是我太垃圾了。最后趁着大佬还在睡午觉没有发力、以及相关技术（JWT）之前开发用过偷了个web题的一血奖，本以为还能蹭个30名万岁，结果比赛DDL当天早上一觉起来被卷王卷下去了，行吧。 CTF 这学期年中的时候参加了学院组织的持续48小时的hackathon比赛，由于是线上，所以差点现场一起卷的感觉。但是瑕不掩瑜，4个人在48小时从0开始卷了个类似大众点评的小程序出来，也算是学了个新技术（虽然小程序其实可以说就是个阉割版和私有版的web）。 hackathon奖状 年末的时候还参加了个比赛，说好10月中旬结束的，结果到现在还没结束，日程表一改又改，也是无语了。...
我的第一个真实项目：总结和经验
almost 4 years ago
我的第一个真实项目 终于，从3月15日开始，我自己独立承担了一个完整的、真实的项目的开发和整个软件生命周期的维护工作：https://data-competition.pku.edu.cn ，第三届全国高校数据驱动创新研究大赛的后台系统（代码目前放在学校gitlab上，以后应该会把代码放到github上）。 虽然这还是一个常规的CRUD项目，但是毕竟是我第一个能够被真实用户使用的系统，我还是比较激动的。项目中途遇到了几次重构，最后出现了一次生产事故，其他的总体流程还是比较顺利的。 项目现在已经基本结束了，这里写一篇总结文，介绍一下项目的架构、演进、自己设置的一套前后端共用API的机制、以及在这个过程中的经验。 系统功能、架构、规模 下面是系统的用例图，主要完成一个比赛报名系统的用户管理、团队管理和上传提交文件操作，还对管理员实现了查看用户和团队信息以及群发邮件功能。 用例图 总的来说，系统是一个做了SSR的前后端分离的TypeScript全栈项目，下表为项目的技术栈。 部分 技术栈 编程语言...
一次生产环境的文件丢失事故：复盘和教训
almost 4 years ago
生产事故 我最近负责了一个比赛后台网站的开发和维护，在比赛临近结束、正在接受用户提交成果文件的时候出了一场生产事故，造成了丢失了一段时间内用户上传的文件。本文主要讲讲生产事故从发现到确定影响范围到确定原因的过程。在整个过程中，后台程序记录的日志起到了巨大的作用。 关于这个项目的总结，可以查看这篇文章：我的第一个真实项目：总结和经验。 TL;DR 要素 内容 表现 丢失2021-07-16 09:00:10至2021-07-17 18:00:57期间所上传的文件 原因 7月16日的一次提交，使得之后文件上传到了一个容器内部的、没有mount出来的目录，容器重启后，这些文件丢失了...
react-typed-i18n: 使用Template Literal Types实现强类型的i18n
almost 4 years ago
react-typed-i18n 最近学习了一下TypeScript最新的Template Literal Type特性，突然想起来可以使用这个实现一个使用字符串字面量的i18n库，以用来替换之前的使用了一些黑魔法的simstate-i18n库，也在这个新库中解决一些技术债，例如只使用React Context、加入测试、增加一些新功能等。 新的库名字叫react-typed-i18n（GitHub）。花了一个周末将功能和测试写好发到了npm上，并很快把本网站用这个新库重写了，体验比较好。 于是通过此文章介绍一下i18n的概念、常见实现方式以及本库的亮点，其中介绍部分的内容使用了之前写过的关于simstate-i18n的文章 Strongly Typed i18n with TypeScript。要想更详细的了解一些i18n的内容以及当时写simstate-i18n的考虑，请查阅此文章。...