PHP
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Functions
-
Section 4: Object-Oriented PHP
-
Section 5: Working with Data
-
Section 6: Modern PHP (PHP 8)
-
Section 7: Working with Files and Networking
-
Section 8: Common PHP Frameworks Overview
-
Section 9: Tooling and Ecosystem
-
Section 10: Practical Projects
-
Section 11: Interview Practice
-
Section 12: More Standard Library
-
Section 13: Data Structures and Algorithms in PHP
-
Section 14: More Practice Exercises
-
Section 15: More Security and Best Practices
-
Section 16: More Testing and Tooling
-
Section 17: WordPress-Style CMS Concepts
-
Section 18: Advanced OOP Practice
-
Section 19: More Web Fundamentals
-
Section 20: Database Practice
-
Section 21: PHP Manual: Array Functions
-
Section 22: PHP Manual: Date and Calendar Functions
-
Section 23: PHP Manual: Filesystem and Directory Functions
-
Section 24: PHP Manual: Filter and Var Handling
-
Section 25: PHP Manual: Math Functions
-
Section 26: PHP Manual: JSON and XML
-
Section 27: PHP Manual: Network and Stream Functions
-
Section 28: PHP Manual: Error and Exception Handling
-
Section 29: PHP Manual: Output Control and Misc
-
Section 30: PHP Manual: FTP, Zip, and Mail
-
Section 31: Modern PHP Frameworks Deep Dive
-
Section 32: PHP Design Patterns
-
Section 33: More Practice Exercises
-
Section 34: PHP Performance and Deployment
-
Section 35: More Interview Practice
-
Section 36: More PHP Standard Library
-
Section 37: PHP Concurrency and Async
-
Section 38: More Web Development Practice
-
Section 39: PHP Testing Deep Dive
-
Section 40: Composer and Package Development
-
Section 41: PHP Security Deep Dive
-
Section 42: More Practical Projects
-
Section 43: Legacy PHP Maintenance
-
Section 44: More Algorithm Practice
-
Section 45: Final Practice and Review
-
Section 46: PHP for E-Commerce Patterns
-
Section 47: PHP API Design Deep Dive
-
Section 48: PHP Caching Strategies
-
Section 49: PHP Queue and Background Jobs
-
Section 50: PHP Multi-Tenancy Patterns
-
Section 51: PHP Real-Time Features
-
Section 52: PHP CMS and Content Modeling
-
Section 53: PHP Internationalization
-
Section 54: More Framework-Specific Practice
-
Section 55: PHP Legacy Code Refactoring
-
Section 56: More Practice Projects Round 2
-
Section 57: PHP Command-Line Applications
-
Section 58: PHP and Microservices
-
Section 59: More Interview and Review Round 2
117: cURL Multi-Handle for Concurrent Requests
You've probably used curl_exec() a thousand times. It's the reliable workhorse for grabbing data from an API. But there's a fundamental problem with the way most people use it: it's blocking. When you call curl_exec(), your PHP script just sits there, staring at the wall, waiting for the remote server to respond before it moves to the next line of code. For one request, that's fine. But imagine you're building a dashboard that needs to pull data from three different sources—say, a user's profile, their recent notifications, and a system status check.
The Sequential Bottleneck
The naive way to handle this is to put your cURL handles in a loop and execute them one by one. It looks clean in the code, but it's a performance nightmare in production. If the Profile API takes 500ms, Notifications takes 800ms, and System Status takes 400ms, your user is staring at a loading spinner for 1.7 seconds. You're paying the cost of every single network round-trip sequentially.
// The "Slow" Way $urls = ['https://api.example.com/profile', 'https://api.example.com/notifications', 'https://api.example.com/status']; $handles = []; $results = []; foreach ($urls as $url) { $ch = curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $results[] = curl_exec($ch); // The script pauses here every single time curl_close($ch); }I've seen this exact pattern crash sites during traffic spikes. When an external API starts lagging, your PHP processes stay open longer, your connection pool fills up, and suddenly your entire server is unresponsive just because a third-party notification service is having a bad day.
Firing All Your Shots at Once
This is where
curl_multicomes in. Instead of waiting for one request to finish before starting the next, we initialize a "multi-handle." Think of this as a manager that oversees a group of individual cURL handles. You add all your requests to the manager, and then you tell the manager to execute them all concurrently. Now, the total wait time isn't the sum of all requests; it's simply the duration of the slowest single request. That 1.7-second wait we talked about? It just dropped to 800ms.The syntax is a bit more verbose, which is why people avoid it, but the trade-off is worth it. You have to use a
do-whileloop to keep the multi-handle running until all the requests are processed. I usually wrap this logic in a helper method because writing it out every time is a chore.$mh = curl_multi_init(); $handles = []; foreach ($urls as $url) { $ch = curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $handles[] = $ch; curl_multi_add_handle($mh, $ch); } // Execute the handles $running = null; do { curl_multi_exec($mh, $running); // This prevents the loop from eating 100% CPU while waiting for a response curl_multi_select($mh); } while ($running > 0); // Collect the data $results = []; foreach ($handles as $ch) { $results[] = curl_multi_getcontent($ch); curl_multi_remove_handle($mh, $ch); curl_close($ch); } curl_multi_close($mh);The Complexity Trade-off
Now, before you go replacing every
curl_execin your codebase, let's talk about the cost. Multi-handles are significantly more complex to debug. If one request fails, you can't just catch it in a simple loop; you have to inspect the individual handles after the multi-execution is complete. You also have to be careful about resource limits. If you try to fire off 100 concurrent requests to a single API, you're basically performing a small-scale DDoS attack on your provider, and they'll likely rate-limit or ban your IP address.My rule of thumb is this: if you have more than two external requests that don't depend on each other, go multi. If Request B needs the ID returned by Request A, you're stuck with sequential calls anyway. But for independent data fetching, blocking is just wasted time.
📋 Practical Task
Exercise: Concurrent Crypto Price Aggregator
You need to build a script that fetches the current prices of Bitcoin, Ethereum, and Litecoin from a public API (like CoinGecko or a similar mock service).
Requirements:
- Create an array of three different API endpoints for the three cryptocurrencies.
- Implement a
curl_multiworkflow to fetch all three prices concurrently. - Ensure you use
curl_multi_select()within your loop to maintain CPU efficiency. - Once all requests are finished, loop through the handles to retrieve the content and print the prices in a clean list.
- Add a timer using
microtime(true)at the start and end of the execution to prove that the total time taken is closer to the slowest single request than the sum of all three.
There are no comments for now.