Server has been working fine for the last few days. Today, we have been receiving a CORS error, as well as hanging calls with over a minute responses.
Access to XMLHttpRequest at ‘https://paowcrhhshcz.grandmoralis.com:2053/server/users’ from origin has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Hey @fost
Please make sure you provided the correct serverUrl and appId to your frontend. Also check if your server is not archived. Please provide a response from getServerTime
it looks like the server should be accessible now, but something is using 100% of the processor, maybe you need to optimise something in the cloud code, or maybe there is some infinite loop, it can happen when you use afterSave and modify the object in the same hook and call .save again for example
are there other metrics or logging techniques that can be used to help understand why something is using 100% of the processor? the server is constantly at 96-100% of processor usage. the afterSave is only being used on eventsync events, and saved into a new object so that does not appear to be the problem.
You could add some logging to see how much time it takes for a function to execute and how many times it executes
none of the functions appear to be executing more than intended (mostly once). as the CORS policy (rather its more likely a 504 gateway timeout error) is no longer persisting. do I still need to be concerned about this potentially happening in the future? Is this known to be a reoccurring issue, and are there steps I can take to prevent it?
is there any other reason why the processor would be running at 100% at all times? None of the cloud functions appear to be executing at the moment on the current test server.
it looks like the CPU on your server is no longer in 100% all the time now, it is more like 70-80%
it can happen to receive CORS errors in case of timeout, if the server is not able to respond in an amount of time then we could receive CORS error
it looks like you have close to 800MB in mongo db, maybe you synced some events or transactions there that used the processor
CPU seems to still be stuck at 100%, while currently no transactions/events should be getting synced.
70-80% on idle doesn’t sound ideal either does it? Is 800mb reaching the limits of Moralis DB’s storage capabilities? Please advise.
those 800MB is not the limit, but something it is processing there to keep the processor in 70-100%
it could take time to process those 800MB if you don’t have the proper indexes in db
you could try to do a backup to your cloud code, then to delete it and to see if the CPU usage drops and then to add one by one the cloud functions.
i have completely removed my cloud functions like so:
server still at 100% cpu and transactions are still taking over a min. for Moralis authenticate call
While all the cloud functions are deleted, we noticed that the problem may be the fact that we are using event sync. With our test server, is it expected that we should be able to listen to at least 8 contracts? Will this change with using an upgraded server/mainnet server? Another reason could be the fact that we have onboard ~200 users onto our platform with the testnet. Is testnet capable of handling this type of load?
the problem would not be the number of event syncs, but if one of those events syncs has 100k+ entries
also with 200 users you may want to disable historical sync so that you don’t get all the past transactions for those users also synced in your Moralis server db.
An upgraded server will have more processing power and will be able to handle more.
The bottleneck is how much real-time processing the server has to do, how many onchain transactions from events and user transactions need to be inserted in the DB in real time
Let’s say you have 200 users signing up at the same time and each has 1000 past transactions - the server needs to process 200,000 transactions all at once - a free machine would die quickly here. Therefore we recommend to turn off historic sync for users if you don’t need it.
On top of that you may have real-time processing from contract events and real-time users doing new transactions.
If you have a lot of requests flying in real-time it’s time to upgrade
the free machine is can only do so much 
