Good to hear it's going now.
I perhaps should clarify the meaning of those constants you changed, as they probably don't do quite what you think. JOBE_MAX_USERS sets the number of simultaneous jobe tasks that can be running at a given time, but that's actually not the point at which the system overloads. If additional jobs come in when no jobe users are available they go into a polling loop, sleeping for one second every second, waiting for a free jobe user. Only after MAX_RETRIES fails (currently 8) does the job return a RESULT_SERVER_OVERLOAD failure condition. So Jobe is probably more robust in the face of sudden peak demands than you were thinking. We run Python tests and exams with up to 500 students on an 8-cpu Jobe server and the Jobe load factor rarely gets over 2, at which point the server is only 25% busy. I would still be comfortable with a load factor that hit 10 - 12 provided it was short lived. So I doubt you need to change the Jobe configuration constants from the default values and in fact I fear you might actually be degrading the performance, unless you have more than 8 CPUs on your server.