-4

So basically, it is a web server that is hosting a php project. The project accepts some inputs from the users and send them to the server via ajax for validation each time the check button is clicked. Then the result is coming back to the client via json.

  • What happens if multiple users send requests to the server concurrently?
  • Is that important to prevent that? (Make the users fill in all the inputs before sending the requests)
  • How can i know if the server can handle those requests based on the concurrent users?

  • What type of testing is the reduction of those http requests?

6
  • If there are many of those users, that's called a DDoS attack. Mar 11 '18 at 11:44
  • @πάνταῥεῖ i believe most hosts are optimized to prevent that
    – csandreas1
    Mar 11 '18 at 12:12
  • Not out of the box unfortunately. Mar 11 '18 at 12:19
  • Is that a good practise to prevent those requests from Javascript? for example if users filled all the inputs then proceed to php for validation instead of checking one by one (the inputs are a lot)
    – csandreas1
    Mar 11 '18 at 12:42
  • PHP is too late, that's already running server side. Mar 11 '18 at 12:45
3

What happens if multiple users send requests to the server concurrently?

It depends on what the requests do. If they're just reads, nothing happens. If they're, say, incrementing counters, or changing variables, then Alice might send "SET x=15" while Bob sends "SET x=42" and Alice might think x is set to 15 while it is actually set to 42. In complex scenarios where data are then reused for calculations and error might snowball fast, this is very bad and you avoid it with several so-called locking strategies.

Is that important to prevent that? (Make the users fill in all the inputs before sending the requests)

That's surely beneficial: ensure that the least possible data in the least possible number of calls is subjected to slow network round-trips. So, do also all the checks you can client-side. But keep the checks server side too, as the clients must never be trusted.

How can i know if the server can handle those requests based on the concurrent users?

You test. You use tools like Apache's ab or httperf or Casper-Load or whatever.

What type of testing is the reduction of those http requests?

I guess you might call it efficiency, but it's a metric and not a test, and however you must also remember that you're seeking a trade-off; you must balance development effort, maintainability, expandability, performance and data integrity. There most definitely isn't a one-size-fits-all solution, you need to verify what your design requirements are.

Update based on comments

Actually, my project accepts inputs from the users and sends them to PHP for validation

Then perhaps most of the issues disappear. If the "validation" is completely defined by the user's request, and all users have a single login each, it will never happen that one user's request can interfere logically with another's.

There might be resource contention (e.g. one validation takes 2 seconds of 100% CPU, then you don't want more than one request every 2 seconds, or the server would lag behind). You can make this a UX issue by creating a "ticket service" by which you quickly "reserve" a ticket and the server books your validation for, say, 60 seconds from now. The client code is then forced to wait (displaying a count-down) and submit the request only one minute later.

Otherwise, you need no special "defenses" - PHP threads will answer each to their own requestor, the HTTP protocol takes care of that.

How could i prevent PHP from sending a response if a validation is wrong?

You must not. You always send a response, you just say 'OK' or 'Wrong'. If you don't send the response, the client is left hanging, and the user dissatisfied. If you can't perform the validation you send a HTTP error code stating why it is so (40X for user error, 50X for server errors).

0

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