Edit:
I went ahead and ran some performance tests again with optimizations with better results.
Preface
This is the first post in a se...
For further actions, you may consider blocking this person and/or reporting abuse
Nice to see a Symfony article on dev.to ;) I plan to write something about it soon as it is my favorite framework.
Some comments:
Regarding your performance results, have you optimized your application for production according to this?
This has tremendous impact on performance, mostly the optimization of the autoloader.
I would also recommend replacing Apache with Nginx.
And would be nice to know, how many time of your requests is spent on the DB itself. From your slowest requests with many concurrent users, the bottleneck might be the DB itself and not the framework.
About the ORM performance, I think we would need to dig deeper to understand what is slowing it down. It could be the query itself or the object hydration. But If I understand your query, is always returning only 1 result from your "league_player_table" right? Doesn't really make sense that performance difference.
Still, I have not seen your code in detail, but I am curious. I might try something if I have some time.
ORMs are a great tool, but need to be understood what they are doing under the hood.
Loading 10.000 objects into memory is not a viable option, for example ;)
Well, to be correct Symfony 4 doesn't ship with any Persistence adapter by default. Yes, Doctrine its the most common and I would say recommended but you can easily use anything you want, even Laravel´s Eloquent.
This is one of the beauties of Symfony. Start small and add more things as you need need instead of the other way around.
Keep writing ;)
Opcache is enabled to the default settings which is the biggest boost to performance. I could change that to allow more files. I did just now try out composer optimize and got around 38ms at 50 concurrent users for raw sql, huge improvement! I have tested a barebones golang implementation of this type of endpoint awhile back with far far more many concurrent connections before the database started to choke, but I will look into it more just in case. Query time is about .5ms in this scenario.
One note for the ORM is it initiates 3 queries vs 1 here for a total query time of about 1.5ms and has to hydrate 3 objects I believe. I tried to make the endpoint something that might be a common scenario rather than a 100% optimized one. Perhaps that is not entirely fair though.
Either way it seems I need to update the performance section (and my repo) with some tweaked configuration. Thanks!