@MarkKaplun fixing this would require technology not present on 95% of hosts

there's no atomic operation to get an option and fii it has a value set it to another value else do something else

the current situation is good enough for most

multiple machine setups are a minority

REST API requests aren't all POST/PUT

and it isn't just an admin equivalent

if you're dealing with a multi machine setup then you're already in manual cron territory that would benefit from a managed cron runner or a crontab

otherwise there's lots of issues, particularly that show up in cron based syndication

@TomJNowell, you can use flock to simulate an option lock, just lock a file at the path options/$option_name. Not that I think this is how you should use a lock, you probably should lock cron when it processes one scheduled event.

or just when it access the cron option

and yeh, not all json api is doing writting, but separating in your loadbalancer/proxy to which server a request should go based on the method sounds like a real headache, and I can't see what does it solve which can not be avoided by pinning a user to a specific server

@ChristineCooper To be honest that is quite easy to achieve database-wise. If you have a properly designed database with indexed keys, relations and proper column types, you could query hundreds of millions of rows within milliseconds

It's not possible in a WP context since WP doesn't believe in any of those and it takes like a second for the core itself to load

But if you manage to develop a light API that integrates with your database, you won't even need to pay for a service, of course it depends on the data structure which again WP doesn't score well here

I'm thinking about writing a WP package that does this but I'm sure WP gods will crucify me and expect it to load the core before connecting to DB which defeats the purpose

@MarkKaplun you can allocate more servers to GET requests than POST/PUT, and you can put all your write servers in one place

@JackJohansson calling WP rest api an API is a joke. why would an API need to create all kind of objects that should be available only at the UI (and rest API waste time on doing translations of strings in all kinds of situation if not at all of them), so if you want a fast API you do it without initializing the fall stack. there is a short_init define that you might be able to use to get the "must have" without parsing wp-config by yourself.

So @TomJNowell you agree with me that you go cluster only if you must and/or have the devops resources?

I think you're being more ideological and constricting than practical reality

perhaps it's time now to say it depends to someone other than Jack :D

@MarkKaplun I agree with that one. One of the aspects of an API is to quickly provide data without the overheads of loading an entire UI + its dependencies, and booting an entire platform just to do that seems like an overkill

@TomJNowell Thanks To that would really lift some pressure off of me

Being a dependency all the time sucks