Introduction
Hypervel is a high-performance PHP framework inspired by Laravel, offering native coroutine support for developers building high-concurrency and I/O-intensive applications. Created by Albert Chen, it is an unofficial framework that adopts Laravel’s elegant development experience while leveraging Swoole's asynchronous capabilities.
Since there's Octane package maintained by the official team, why do we need a new framework? It may not seem wise to reinvent the wheel, does it?
Why not Octane?
While Octane impressively speeds up Laravel's performance by running the application in the long-lived lifecycle, which eliminates the cost for bootstrapping the framework each request, it can't solve performance issues brought by blocking I/O.
For example, imagine building an AI-powered chatbot with Laravel. Let's say each conversation API takes only 3~5 seconds to respond. If you run your Octane application with 10 workers, how many requests can your application handle at the same time if there are 100 concurrent requests? The QPS (Queries per Second) for your application will be less than 3. Why is this happening?
This occurs because Octane doesn't provide non-blocking I/O capabilities to Laravel. All the workers remain blocked until the end of these I/O requests. Furthermore, due to backward compatibility constraints of the current framework, Laravel has less possibility to support coroutine features in the near future.
You can refer to this issue for more details.
Features of Hypervel
Hypervel is built on Swoole extension, and all components support coroutines out of the box. Hypervel ports many core packages from Laravel while maintaining familiar usage patterns, making it instantly accessible to Laravel developers.
This framework combines the elegant and expressive development experience of Laravel with the powerful performance benefits of coroutine-based programming. If you're a Laravel developer, you'll feel right at home with this framework, requiring minimal learning curve.
You can find more practical code examples in Coding Like in Laravel.
Here are some key features:
- Development experience extremely similar to Laravel.
- Extremely high performance, with QPS 10 times higher than Octane in non-I/O scenarios, and hundreds of times higher in I/O-intensive scenarios.
- Coroutine support out out the box, with even PHP's built-in I/O functions automatically being hooked to support coroutinies.
- Support for object pools and connection pools, such as database, redis and http clients
- Seamless two-way communication with your existing Laravel projects through Cache, Lock, and Queue.
- Coroutine support not limited to handling HTTP requests. Queue and Scheduling can also leverage coroutines, allowing a single process to achieve the concurrency that would require hundreds of workers in Laravel.
This is an ideal choice for building microservices, API gateways, and high-concurrency applications where traditional PHP frameworks often encounter performance constraints.
Coroutines
Coroutines are functions that can pause their execution and later resume from where they left off, maintaining their state between pauses. Think of them as functions with multiple entry and exit points.
When a coroutine encounters an operation that would normally block (like waiting for network data), instead of blocking the entire program, it yields control back to a scheduler. The scheduler can then run other coroutines until the blocking operation completes.
In Hypervel, I/O components such as database connections, file operations, HTTP clients, and even all native PHP I/O functions work as coroutines. The overhead for each coroutine is extremely lightweight compared to processes or threads, making them ideal for concurrent I/O operations. This architecture enables Hypervel to perform excellently in I/O-intensive scenarios.
You can learn more about how coroutine works in Hypervel in Coroutine section of the official documentation.
What's more, coroutines are not only supported in request handling. In Laravel, the only way to improve concurrency in queues or task scheduling is to increase the number of workers on the machine. In Hypervel, you can run multiple jobs simultaneously under coroutine scheduling. This means one worker process can act as hundreds of traditional workers in Laravel.
Benchmark
The benchmark tests cover two distinct scenarios to evaluate performance under different conditions:
-
Simple API Test: A basic hello world API endpoint. No middleware applied.
-
Simulated I/O Wait Test: Sleep for one second to simulate I/O wait time
Laravel Octane's QPS number is close to 8, but because it differs so significantly from Hypervel's numbers, it appears this way when generated in the chart.
You can see benchmark for more detailed information.
Prerequisites
Hypervel has a few system requirements. You should ensure that your web server has the following minimum PHP version and extensions:
- PHP >= 8.2
- Swoole PHP extension >= 5.1
- Pcntl PHP extension
You can install Swoole extension via PECL:
pecl install swoole
Mac users can also install Swoole via brew:
brew tap shivammathur/extensions
brew install shivammathur/extensions/swoole@8.3
Using
shivammathur/extensions
can help you solve common issues while installing swoole on Apple M1 environments.
For full requirements, you can refer to server requirements on the website.
Installation
You can create a new Hypervel project easily via Composer's create-project command:
composer create-project hypervel/hypervel example-app
Once the project has been created, start Hypervel's local development server using serve
command:
php artisan serve
Once you have started the HTTP server, your application will be accessible in your web browser at http://localhost:9501
by default.
Conclusion
Undoubtedly, Laravel is the top choice for building web applications in many use cases, especially with its mature community and rich ecosystem.
However, in some high-concurrency or intensive I/O scenarios, you can definitely give Hypervel a try for ultra performance and enjoy Laravel-like development experience at the same time.
You can get started with Hypervel by checking out the official website.
Top comments (5)
The problem I have with solutions like this, is that they introduce leaking memory problems.
The main reason I'm using php is to avoid thinking about memory leaks. Statelessness is under appreciated.
I would not recommend this to start with. I see this as an option when a more modular structure is not wanted for an application. A modular structure gives more opportunities to tackle the performance issues.
The problem is that frameworks stops PHP from being something it doesnt should be. Most of PHP devs doens't understand what is purpose of extensions like Swoole at all, thet just can't use something they dont knew about. Laravel still doesnt have type-hints because of "compability with old PHP versions which are used by 5% of servers". Having such great extension for PHP as swoole which is boosting lagnuage and possible use-cases to next level. I'm using swoole for 100% of my php projects no exception what they do. And if we have one more perfect solution for this scenario, i can only put my Like here and wish authors to continue their job and show to world their vision on how to solve some scenario, keep going! And devs should have to understand what framework is best option for their task not just having "im taking laravel because i have such advice" in their mind.
I understand your concerns about memory leaks with long-lived PHP applications like Hypervel or Laravel Octane. For most CRUD applications with moderate traffic, you're right that traditional stateless PHP frameworks work perfectly fine. The request-response cycle naturally cleans up resources, which is one of PHP's greatest strengths.
However, I'd suggest that memory leaks are primarily a result of development practices rather than the programming language itself. Stateless environments simply hide these issues by restarting everything. In most other programming languages, managing long-lived resources is a standard skill developers must master.
I agree it is a developer problem, instead of a language problem.
It is because of the out of the box PHP experience that developers are not going to think about memory leaks as a problem when the application slows down, or when there are unexpected errors.
It is because of that consequence I suggest not to use it from the start. When there are scaling issues the framework can be a solution. I think it is a good option to have.
I agree. This framework is especially for developers who encounter high concurrency or intensive I/O scenarios. For general use cases, traditional PHP just works fine.