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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!