I Tested the Doppar PHP Framework: Benchmarks & Architecture Review

1. What I Liked: Startup, Queues & Schedulers

Lightweight startup and small footprint

The first thing I noticed was how light it is. Doppar's cold start (the first request after a restart) took about 41 milliseconds. Laravel took about 142 milliseconds in the same test. For one request, Doppar loads around 126 files and Laravel loads around 429 files. In terms of Composer dependencies, Doppar uses 49 packages, while Laravel uses 78 packages.

Most of the basics are already inside: routing with attributes, a template engine, its own database layer, a queue, and a scheduler. The code reads cleanly.

Resilient queue workers

The queue impressed me. I sent 1,000 jobs to four workers. Nothing got lost and nothing ran twice. Then I killed one worker halfway through, and all 1,000 jobs still finished. Failed jobs were saved, and I could retry them.

Steady scheduler performance

The scheduler was steady too. I ran a task every 5 seconds for 30 minutes. It ran 363 times with no long gaps, and memory stayed flat throughout the entire test.

Competitive database performance

On database work, Doppar kept up. On the page that loads items together with their related data, it was slightly ahead. With MySQL, the two were about the same.

2. Test Environment & Methodology

I built the same small API in Doppar and Laravel, and checked that both gave the same answers. Both ran in production mode, on the same computer, with the same data and the same PHP version:

• Hardware: AMD Ryzen 5 5600G with 6 cores and 27 GB of memory
• Versions: Doppar 4.8.4, Laravel 12.70.2, PHP 8.5.12
• Operating System & Runtime: Ubuntu, PHP 8.5
• Load Generation: For the load I used a common tool called wrk. Each test ran five times for 20 seconds at 50 concurrent users, and I took the middle result.
• Environment Notes: This isn't an official benchmark. It's one person, one machine, and a few hours of testing. I also had other programs open on the same computer, so don't read much into small differences. Notably, between my first run and my final run, I rebuilt Laravel's production caches, and its speed on the simplest page almost doubled. I didn't isolate the exact cause, but it shows how much the setup changes the result. If you see a big speed claim, ask how the other framework was configured.

3. Speed Results: Doppar vs. Laravel

Here is how many requests each framework handled per second with 50 users at once. Higher is better:

4. Evaluating the Marketing Claims

A blog post about Doppar says it can be 7 to 8 times faster than Laravel. I don't know how that test was done, so I can't compare it with mine. In my setup, Laravel was faster on the simple pages and the two were close on the database-heavy pages. I didn't see anything near 7 to 8 times.

I checked a few other claims too:

• About 2 milliseconds per request: With a single user, I got about 4.9 milliseconds for Doppar and about 2 milliseconds for Laravel.
• The speed table on Doppar's website: On my computer I reached about 70 percent of those numbers. My hardware is different, so that's not a surprise.
• No facades: I found 24 facade classes in the code, and the official docs have a page about them.
• Minimal dependencies: Doppar has fewer packages than Laravel (49 against 78), but more than CodeIgniter (3) or Slim (11).

These are just what I saw on my computer. Your results may differ.

5. How It Compares to Other Frameworks

Laravel is the closest match, since both come with the basics built in. On my numbers, Laravel was faster on simple pages and the two were close on database-heavy pages. Laravel has a much bigger community and many more add-on tools, so it's the safer default for most projects. Doppar's case is that it's smaller, starts faster, and keeps the basics in one light package.

Slim, CodeIgniter and Symfony are built differently. In an earlier, smaller test (a different session, so only a rough guide), all three were faster than Doppar on the pages I tried:

• Slim is a very small tool that gives you routing and little else, so you add the rest yourself. If you only need a tiny API, Slim is lighter and faster.
• CodeIgniter is light and simple.
• Symfony is big and flexible, made of many parts you pick and combine. If you want a full toolbox with lots of control, Symfony and Laravel are proven choices.

Doppar sits in the middle. It has more built in than Slim, and it's light and quick to start.

6. Sessions: The Critical Part to Watch

A session is a small file the server creates to remember a visitor. In my tests, Doppar started a session on every request, even for a plain API page. I couldn't find a documented way to turn that off for API routes. Laravel, Symfony, CodeIgniter and Slim didn't do this on their API routes.

I found two smaller things as well:

1. With SESSION_DRIVER=cookie, Doppar 4.8.4 still creates normal PHP session files, in /tmp (not in the app's storage/framework/sessions folder, so it's easy to miss). In my re-test, 10 requests without cookies produced 10 files in /tmp and a PHPSESSID cookie. With the default file driver, the same 10 requests put 10 files in the app's session folder.
2. If you pick a session type that doesn't exist, Doppar returns an error message with file paths and internal details, even with debug mode turned off.

The Scheduler: One Small Gap

The scheduler had one small gap. Tasks set to run every minute didn't run in the built-in daemon mode, so you still need the system scheduler for those. And if the daemon gets killed, it doesn't start again by itself. You need another tool to restart it, like with most background programs.

7. Seven Pieces of Advice for the Doppar Team

Doppar has a good base and I'd like to see it grow. If I could pick a few things to work on first:

1. Add a simple way to turn off sessions for API routes, and clean up old session files.
2. Check the cookie session option, because it still creates session files in /tmp.
3. Hide internal error details in production, even when a setting is wrong.
4. Share how the speed tests were done (the computer, the pages, and how Laravel was set up) so anyone can repeat them.
5. Make the scheduler docs clearer about every-minute tasks and about restarting after a crash.
6. Cache the table lookup on pages with related data, so it isn't repeated on every request.
7. Add more examples and guides, so new people can get started quickly.

8. Where I Think It Fits & Verdict

I'd look at Doppar for small internal tools and small services. These are places where fast startup and a light footprint help, and one small team controls the whole thing. It's also fun to try if you like young frameworks and don't mind helping them grow.

None of this takes away from what's already good. With these fixes, I think Doppar could be a strong choice for a lot more projects.