Realistically, and speaking from professional experience of over a decade, "creating an order" can be one of the most complex tasks your frontend part (as opposed to admin/cronjobs parts) of the web app is going to do. It is not a rare thing to see dozens of records in a dozen of tables being created/updated at order creation time. All of these "order creation" examples are super naive. Once you develop for a shop that operates in $10M+/year range (i.e. there was probably time and money to bloat all the user/cart/stock/warehouse/sales/dispatch/marketing operations and metadata), god forbid a shop that has lots of legacy code and data structures, you will be fine with anything around 1s at order creation.

(Not that I want to defend Laravel's speed, it's not really anything to brag about, and the typical "cache everyhing everywhere all the time" aswer is not that useful.)

While 500k order does not sound as much - you have to remember an order != a request.

Not to mention that as long as you have a direct sync query to a database - your code will have to wait, lol.

Yeah...

OTOH it makes a point that it solves a real problem. A business processing 500k orders a month is not trivial.

I know it's just meaningless numbers, but our php backend handles 10 orders per second peak. And obviously a order requires many more requests than just 1.

I have a client that handle peaks of 7k requests/s using php-fpm + nginx + MySQL. Using their own custom framework in PHP.

It all sits in a single 5 year old machine with 8 cores and 16GB RAM. Their bottleneck is actually MySQL but they have room to spare so no need for upgrades right now.

I help with an open studio event. We maxed out last weekend at about 350 visitors per minute (about 30%Wordpress and 70%custom php symfony pages) on shared hosting. We have a cdn helping with images and such.