Default keyboard shortcuts for Ghostty terminal emulator. Platform-specific differences are noted where applicable.
| Action | Windows/Linux | macOS |
|---|---|---|
| New window | Ctrl+Shift+N | Cmd+N |
| Close window | Alt+F4 | Cmd+Shift+W |
| name | description | allowed-tools |
|---|---|---|
ast-grep-search |
Syntax-aware code searching that understands code structure rather than just text patterns. Always prefer ast-grep than grep for code searches. |
Read, Grep, Bash(ast-grep:*), Bash(sg:*) |
ast-grep allows searching code based on its Abstract Syntax Tree (AST), enabling syntax-aware pattern matching. It is ideal for finding function calls, method invocations, variable declarations, and other code structures while respecting language syntax.
| #!/usr/bin/env bpftrace | |
| BEGIN | |
| { | |
| printf("Tracing redis-server function \"getMaxmemoryState\" as inlined into \"performEvictions\".\n"); | |
| printf("NOTE: These instrumentation points are from disassembly of the redis-server build:\n"); | |
| printf(" SHA1: 25a228b839a93a1395907a03f83e1eee448b0f14\n"); | |
| printf(" Build-id: 2fc7c1a80ad026179178fff7045bc7fb4ad3f82d\n"); | |
| printf(" Version string: Redis server v=6.2.6 sha=4930d19e:1 malloc=jemalloc-5.1.0 bits=64 build=aa3ee5297f58e2\n"); | |
| printf("\n"); |
| func (p *page) meta() *meta { | |
| return (*meta)(unsafeAdd(unsafe.Pointer(p), unsafe.Sizeof(*p))) | |
| } | |
| func unsafeAdd(base unsafe.Pointer, offset uintptr) unsafe.Pointer { | |
| return unsafe.Pointer(uintptr(base) + offset) | |
| } |
MACD指标由一组曲线与图形组成,通过收盘时股价或指数的快变及慢变的指数移动平均值(EMA)之间的差计算出来。快”指更短时段的EMA,而“慢”则指较长时段的EMA,最常用的是12日及26日的EMA。
Latency,中文译作延迟。Throughput,中文译作吞吐量。它们是衡量软件系统的最常见的两个指标。延迟一般包括单向延迟(One-way Latency)和往返延迟(Round Trip Latency),实际测量时一般取往返延迟。它的单位一般是ms、s、min、h等。 而吞吐量一般指相当一段时间内测量出来的系统单位时间处理的任务数或事务数(TPS)。注意“相当一段时间”,不是几秒,而可能是十几分钟、半个小时、一天、几周甚至几月。它的单位一般是TPS、每单位时间写入磁盘的字节数等。
低延迟一定意味着高吞吐量吗?如果不是,试举出反例。假如有一个网站系统,客户端每次请求网站服务端,网络传输时间(包括往返)为 200ms,服务端处理请求为10ms。那么如果是同步请求,则延迟为210ms。此时如果提高网络传输速度,比如提高到100ms,那么延迟为110ms。这种情况减少延迟似乎确实可以一定程度提高吞吐量,原因主要在于:系统性能瓶颈不在于服务端处理速度,而在于网络传输速度。 继续假设将同步请求改为异步请求,那么现在延迟为100ms,延迟降低了,但吞吐量保持不变。所以这是一个反例。
除了上面这个反例外,还有一个更生动的反例:火车、飞机运煤:从山西到广州运煤,一列火车100小时(包括往返)可以运输10000t煤,而一架飞机20小时(包括往返)可以运输100t煤,显然飞机运煤的延迟明显低于火车运煤,但如果测试运10000t煤,则火车运煤的吞吐量远高于飞机:
火车运煤的吞吐量为100t/小时,飞机运煤的吞吐量为5t/小时,我们可以将上面的运煤场景类比软件系统,火车、飞机运煤可以比作Web服务器处理请求,比如Apache和Nginx。在并发请求数不高时,比如10000(我假设的)以下时,也许Apache的吞吐量可能优于Nginx,但在大于10000时Apache的吞吐量就开始急剧下降,而Nginx的吞吐量相对之前比较稳定。所以比较Web服务器的吞吐量时,必须观察在并发请求数逐渐递增情况下它们各自的表现。根据延迟和吞吐量我们还可以计算并发度(Concurrency),公式如下: