DEV Community: momina ayub15

Why Your Lambda Function Is Slow (And How to Fix It)

momina ayub15 — Wed, 23 Jul 2025 10:43:12 +0000

TL;DR: Your AWS Lambda isn’t slow because it hates you. It’s slow because of cold starts, bloated packages, bad VPC configs, and more. Here’s how to fix all that—fast.
VISIT MY BLog

The Problem: “My Lambda is so slow!”

If you've ever yelled this into the void (or worse, into Slack), you’re not alone. AWS Lambda is an amazing tool for scaling backend workloads—until it randomly takes 2 seconds to do what should take 200 milliseconds.

You might think, “Is it AWS? Is it me?” Spoiler: it's mostly you. But also a bit of AWS. Let’s break it down.

Cold Starts: The #1 Culprit

Cold starts are what happen when AWS has to spin up a fresh container to run your function. These typically happen when:

A function hasn’t been invoked in a while
You're deploying a new version
Your concurrency suddenly spikes

Why It's Slow?

Each cold start involves:

Booting up a container
Initializing the runtime (e.g., Node.js, Python, etc.)
Running your function’s initialization code

This can add 100ms–2s to your first call.

Fix It This Way

Use provisioned concurrency: This keeps Lambda “warm” all the time.

Keep your dependencies minimal: The larger your bundle, the slower your cold start.

Choose faster runtimes: Node.js and Go have quicker cold starts than Java or .NET.

Bloated Dependencies = Bigger Latency

If your Lambda package is huge (like 100MB+), you’re basically asking AWS to uncompress and boot a whale.

Why It's Slow? More dependencies mean:

Slower cold starts
Higher memory usage
Slower file system access (especially if using /tmp)

Fix It by Bundling only what's needed. Use tools like esbuild or webpack.

Also, Externalize AWS SDK if you're on Node.js 18+. It's now available in the Lambda runtime and. Remove devDependencies from deployment packages.

VPC Configuration May Be a Black Hole

If your Lambda needs to access resources in a VPC (like RDS or ElastiCache), it can suffer a ~400ms delay just to attach an ENI (Elastic Network Interface).

Why It's Slow

Creating ENIs adds latency

It slows down every cold start

Solution

Don’t run Lambdas inside a VPC unless you absolutely need to
Use Amazon RDS Proxy to speed up DB connections
Place resources outside the VPC when possible (e.g., S3, DynamoDB)

You're Not Reusing Connections

Opening a new DB or API connection on every invocation is a performance killer.

Reason it's not fast:

Connection handshake overhead
DB resource exhaustion
Timeouts on concurrent executions

Fix It

Reuse connections by creating them outside the handler function

// Bad
exports.handler = async (event) => {
  const db = new MySQLConnection();
  await db.connect();
  ...
}

// Good
const db = new MySQLConnection();
db.connect();

exports.handler = async (event) => {
  ...
}

Logging Too Much, or Synchronously

Are you dumping huge payloads into console.log? Worse: doing it synchronously?

Why It's Slow

Logging slows down execution
Especially bad if logging big objects or arrays
JSON.stringify is often slow, too

So, minimize logs in performance-critical paths and use async loggers or external log aggregators. Also, avoid stringifying large payloads unless needed

You’re Not Testing in the Real Environment

Local runs are not a good representation of how your function performs in AWS.

Use AWS CloudWatch to view invocation durations
Enable X-Ray for tracing bottlenecks
Benchmark using artillery, autocannon, or serverless-artillery

Important Tips

Use layers wisely: Layers help reduce size, but don’t magically improve cold starts. Test their impact.

Keep function warm: Use a ping Lambda or a scheduler to keep your function alive.

Use async initialization: Lazy-load large modules or config if they’re not always needed.

Final Thoughts

Lambda functions can be lightning-fast—but only if you treat them like race cars, not cargo ships. Strip them down, warm them up, and give them the right track to run on.

Got questions or want a walkthrough on any part of this? Drop a comment or hit me up!

10 Performance Tips for Scaling Your Node.js API

momina ayub15 — Wed, 09 Jul 2025 11:05:51 +0000

Scaling a Node.js API might seem simple at first—spin up more instances, use async code, and throw in a database. But in practice, it’s a balancing act between efficient resource usage and low-latency responses. Node.js runs on a single-threaded event loop, which makes it incredibly performant for I/O-bound operations—but also uniquely vulnerable to bottlenecks caused by blocking code or unoptimized logic.
Visit my Website

Performance isn’t just a developer obsession. It directly impacts user experience, SEO, and infrastructure costs. A slower API could mean abandoned sessions, dropped purchases, or skyrocketing AWS bills. Whether you're building a REST API, GraphQL service, or microservice backend, it’s essential to understand where your bottlenecks lie—and how to squash them.

This post covers 10 practical performance tips for backend engineers working with real-world Node.js apps. These are based on patterns I’ve encountered while deploying services on AWS, working with serverless and containerized environments, and handling traffic spikes without scaling up like crazy.

1: Use Asynchronous and Non-Blocking Code Wherever Possible

Node.js thrives when your code is asynchronous. But one blocking function is all it takes to choke your entire API. Since the Node.js event loop is single-threaded, anything that takes too long—like a for loop over a huge array or a synchronous file read—will block all other incoming requests.

Avoid This:

const data = fs.readFileSync('./bigfile.json'); // Blocking!

✅ Use This Instead:

const data = await fs.promises.readFile('./bigfile.json'); // Non-blocking
Long-running operations—like data parsing, CPU-heavy calculations, or even unoptimized libraries—should be offloaded to worker threads or separate microservices.

Also watch for blocking patterns in loops or recursive operations. If you're working with large datasets, consider using streams, batching, or pagination to minimize memory pressure and event loop delays.

Tools like clinic.js and 0x can help you visualize what’s blocking your event loop in production-like environments.

Tip 2: Optimize Database Queries Before Scaling Infra

It's tempting to scale up your server instances when APIs start slowing down—but the real culprit is often a lazy query. Common issues include:

N+1 queries: where you make one query, then loop over results to make many more
Missing indexes: resulting in full table scans
Lack of pagination: returning thousands of records in one go

Use an ORM with built-in optimizations:

Prisma has excellent support for batching and query logging.

Sequelize also lets you fine-tune queries, includes hooks, and can help mitigate N+1s.

Want to dig deeper? Tools like PostgreSQL’s EXPLAIN, MySQL’s EXPLAIN plan, or Prisma’s query logs are your best friends.

💡 Fixing a slow query is almost always cheaper (and faster) than adding a new server.

3: Bundle Only What You Need (Tree-Shaking & Smaller Packages)

Your app’s performance is directly tied to its bundle size—especially in serverless environments like AWS Lambda where cold start times matter. Even in containerized apps, loading unnecessary dependencies bloats memory usage and slows down startup.Do This:

Avoid importing entire libraries (import _ from 'lodash')—instead, use specific functions (import debounce from 'lodash/debounce')
Switch from require() to import in modern projects for better tree-shaking
Use webpack or esbuild for bundling and pruning dead code Want to audit your bundle? Tools like pkg-size or cost-of-modules can show you which packages are inflating your deploy size.

Smaller bundles = faster cold starts + lower memory overhead = happier users.

4: Use HTTP/2 and Keep-Alive for Faster Client Communication

Still using plain old HTTP/1.1 for your APIs? You’re missing out on serious performance gains.

HTTP/2 supports multiplexing (multiple requests over a single connection), header compression, and more efficient use of the underlying TCP connection. Combine this with Keep-Alive, and you reduce the overhead of repeatedly opening and closing TCP sockets.

How to use:

If you’re using Express, use Node’s built-in http2 module
. Or, enable HTTP/2 and Keep-Alive via reverse proxies like Nginx, CloudFront, or API Gateway on AWS

Bonus: If you're on AWS, API Gateway and ALB support HTTP/2 by default.

This helps reduce latency in high-concurrency environments—especially when clients make many rapid-fire requests.

5: Cache Smartly (Memory, Redis, CDN)

Caching isn’t just for frontends. Backend caching can massively reduce database load and shave milliseconds off your API responses.

Common Types of Caching:

In-memory (like using a simple JS object or lru-cache): great for small, frequently-used values in a single instance
Distributed cache with Redis: use ioredis or node-redis to share cache across multiple instances or services
CDN-based caching (e.g. CloudFront, Fastly) for static API responses like configuration or public data

Route-Level Caching with Express:

const cache = new Map(); app.get('/api/data', (req, res) => { if (cache.has('data')) return res.json(cache.get('data')); const data = getDataFromDB(); cache.set('data', data); res.json(data); });
Set smart TTLs (time to live), invalidate outdated keys, and monitor your cache hit ratio to fine-tune your strategy.
Done right, caching can help you serve more users with fewer resources.

6: Profile and Benchmark Regularly

Before you start optimizing anything, you need to know what’s actually slowing you down. That’s where profiling and benchmarking come in. You’d be surprised how often bottlenecks come from unexpected places—like a logging function, JSON serialization, or even a small piece of sync logic in a loop.

Tools You Should Know:

clinic.js: visualizes your app’s performance and identifies event loop blocks, CPU spikes, and memory issues.
0x: flamegraph generator for CPU profiling.
autocannon: a blazing-fast HTTP benchmarking tool written in Node.js.
wrk: a powerful HTTP benchmarking tool written in C.

Small Change, Big Impact:

Let’s say you’re reading a file on every API call:
// Before app.get('/api', async (req, res) => { const file = await fs.promises.readFile('./data.json'); res.json(JSON.parse(file)); });With autocannon, you might see this handles ~50 requests/sec.

Now, cache the file on first read:
// After let cachedData; app.get('/api', async (req, res) => { if (!cachedData) { const file = await fs.promises.readFile('./data.json'); cachedData = JSON.parse(file); } res.json(cachedData); });
Rerun autocannon, and suddenly you’re at ~1000+ requests/sec. Always benchmark before and after making changes.

7: Use Load Balancing (e.g. NGINX, AWS ALB)

Once you’ve optimized your code, the next step is scaling horizontally—spreading traffic across multiple instances. Load balancers are essential here.

Common Options:

NGINX: great for reverse proxying and load balancing across multiple Node.js processes or containers.
AWS Application Load Balancer (ALB):managed, scalable, and supports things like HTTP/2 and WebSockets.
PM2 Cluster Mode:if you want basic load balancing across CPU cores locally.

pm2 start app.js -i max # Fork app across all available CPU cores

Sticky Sessions:

If your app relies on session state stored in-memory (e.g. for auth), enable sticky sessions to ensure a user always hits the same instance. On AWS ALB, this is called "Session Stickiness".

Pro Tip: Use centralized session stores (like Redis) to avoid relying on stickiness at all.

8: Leverage Worker Threads or Child Processes for CPU-Heavy Tasks

Node.js is amazing for I/O—but it’s not designed for CPU-bound work like image processing, cryptographic hashing, or large JSON transformations. These tasks block the event loop, starving all other requests.

Solution:

Offload heavy work to:

worker_threads: native thread pool in Node.js
child_process: spawn new Node.js processes for full isolation
External microservices: for extremely resource-heavy workloads Example with worker_threads: const { Worker } = require('worker_threads'); function runWorker() { return new Promise((resolve, reject) => { const worker = new Worker('./heavy-task.js'); worker.on('message', resolve); worker.on('error', reject); }); } Keep your main thread light and fast. Push anything heavy to the background.

9: Use Environment-Based Configs for Logging & Debugging

Logging is critical for debugging but, it can become a performance bottleneck if not handled properly in production. Avoid console.log() in high-frequency code paths.

Use Tools Like Winston & pino (ultra-fast logger for Node.js) for this purpose.

Configure different logging levels by environment:

const logger = winston.createLogger({ level: process.env.NODE_ENV === 'production' ? 'warn' : 'debug', });

Why Not console.log()?

It’s synchronous in some environments.
It blocks the event loop.
It floods logs and slows I/O. 🧠 Log what matters, and offload logs to a proper log aggregator like CloudWatch, ELK, or Datadog in production.

10: Monitor in Real-Time and Set Alerts

You can’t fix what you can’t see. Performance issues, memory leaks, and downtime often creep in slowly—unless you're watching your system like a hawk.

Tools to Monitor Node.js Apps:

AWS CloudWatch: great for Lambda, ECS, or EC2-based apps

Datadog: full-stack observability with real-time metrics and distributed tracing

Prometheus + Grafana: open-source stack with customizable dashboards and alerts

New Relic / AppSignal / Sentry: great for error tracking and APM (application performance monitoring)

What to Monitor:

CPU & Memory usage
Response time & latency
Event loop lag
Error rate
Cache hit ratio ⚠️ Set alerts to catch anomalies early. For example: if API latency jumps 3x or memory usage grows steadily, trigger a Slack or PagerDuty alert.

You don't need to do all 10 at once

Start with one or two. Maybe caching your most frequent queries or replacing that sneaky readFileSync()—and measure the impact. Performance tuning is iterative and context-specific.