共 3 篇相关文章
作者基于个人兴趣，在一台旧款4核迷你主机的家庭网络环境下，测试了扫描中国大陆所有公网IP地址的耗时。最终扫描约3.43亿个地址，发现其中约592万个IP可达，总耗时约1小时2分58秒。该测试旨在探索使用单台设备探测全国范围内运营商与云服务商网络连通性、识别故障或劫持情况的技术可行性。 文章核心是介绍了一款由作者重构的网络扫描程序的实现。新版本摒弃了之前依赖libpcap库的gopacket方案，完全基于Go标准库中的icmp与ipv4扩展包构建，无需启用CGO，便于部署与编译。程序架构采用并发模型，主要由三个goroutine协作：一个负责解析APNIC提供的IP网段列表并分发任务；一个负责批量构造并发送ICMP回显请求报文；一个负责监听并接收ICMP回显应答，最终将存活IP输出。代码通过设置BPF过滤器优化性能，并使用进程ID作为ICMP报文标识以准确匹配响应。整个扫描引擎仅约200行代码，展示了使用Go语言进行高效网络编程的典型范例。
这篇讲的是作者通过实测对比，拆解几个关键PostgreSQL参数对查询性能的实际影响。文章没有停留在理论，而是搭建了测试环境，针对 `shared_buffers`、`work_mem`、`effective_cache_size` 等核心参数，设计了不同的配置组合，并用 `pgbench` 等工具跑出了具体的TPS（每秒事务数）和延迟数据。 作者发现，盲目调大内存参数并不总是带来线性提升。例如，`work_mem` 设置过大会显著增加复杂查询的排序速度，但并发上升后反而可能因内存竞争导致整体吞吐下降。而 `effective_cache_size` 的设置，需要更贴合实际服务器的物理内存与磁盘缓存能力，才能让查询规划器做出更优的索引选择。 这些结论直观地说明了参数调优中“权衡”的重要性。文章提供的对比数据和场景分析，对于正在面对慢查询、或是准备进行数据库初始化的运维和开发人员来说，能直接帮助理解每个参数的实际作用边界，避免陷入“参数越大越好”的误区。
测量性能是开发中的常见需求，这篇文章就专门聊了聊在Clojure里这件事该怎么做。 作者从大家熟悉的Java、Ruby的测量方式讲起，自然引出Clojure的实践。在Java中，我们可能会循环调用并手动记录时间；Ruby则有Benchmark模块提供详尽报告。而Clojure，同样可以沿用`System.currentTimeMillis()`这类基础方法进行粗粒度的测量。 这篇文章的核心，正在于展示了如何将已有的经验迁移到新语言生态。它没有停留在语法层面，而是点明了性能测试背后的通用逻辑：无论语言如何变化，测量的核心思路——计时与执行——是相通的。对于已经掌握其他JVM语言或动态语言的开发者，这相当于提供了一份快速上手的指南。 掌握了这种“从已知到未知”的学习路径，你就可以更顺畅地在Clojure中开始自己的性能探查，并为后续使用更专业的工具打下基础。
