2

So I have a Google Cloud AppEngine server which has 2 main jobs.

  1. Every Day at 00:00, download lots of data (Firebase/Async), process it, and send out notifications via HTTP, interact with GoogleStorage, etc..
  2. Listen to different types of requests and send out Notifications via HTTP when received.

So for testing purposes I would just spawn a new thread for every HTTP post or synchronous call in libraries like Google Storage, and while this works, I do not think that this will scale well, and might cause out of memory exceptions.

Im worried that say, there are 1000 post/get requests that need to be made at 00:00, and then if I create 1000 threads, that will cause problems, on the other hand, I could iterate through the requests in a single thread, but then that thread will take a long time to finish.

I thought of using a Executor which has a size of ~10, so that one thread is always available to do the daily processing task, and the other 9 threads are available for any requests that might come in.

Is that a good aproach? Or should the threadpool be dynamically scaled, or queued up?

2

Change task 1 to another time. Preferably a small random number of minutes before or after midnight. This will avoid lots of action at once.

Even if you want something done at midnight, you cannot guarantee absolute precision of running at exactly 00:00.0000000. So see spreading jobs somewhat away from midnight as a feature, something that makes all things simpler, not a bug.

| improve this answer | |
  • 1
    This sounds like two different apps to me,so I'd just make them two different apps. Why add cruft to one app by making it do two distinct things? – Paul May 19 '17 at 0:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.