I am trying to understand how client response time behaves during a traffic surge. Lets say we have a concert ticket website (nginx HTTP2 and a CDN provider for handling requests) which shall release special tickets at a certain (pre-defined) time of the day. Naturally at that point of time, there would be a huge traffic surge for ticket buyers. Is there a way a client (ticket buyer) can always ensure to be first in the queue and get the ticket ? Won't constant requesting the ticket webpage constitute DoS (denial-of-service) attack ?
Tried to read about M/M/1 queue but don't think its used in practice.
Is there a way in HA-Proxy to queue incoming request.
I am trying to throttle request based on certain rate limiting criteria, but my current implementation denies the request or blocks any new connection.
This is a crude implementation at this moment.
Instead of denying the request I want to queue them till my backend recovers.
Also, is there a way in Haproxy to rate-limit or queue request based on IP.
What is the difference between Async Response and Server-Sent Events in Jersey and when to use them?
Both are for different usage, one allows to wait for a slow resource (long-polling), the other allows to send a stream of data on the same TCP-connection.
Here's more detail :
AsyncResponse was introduced in JAX-RS 2, in order to perform long-polling requests.
Client open connection
Client send request payload
Server receive payload, pause/suspend the connection and look for the resources
Then
If timeout has been reached the server can end the connection
Resource is ready, server resume the connection and send the resource payload.
Connection is closed
As this is part of the JAX-RS specification, so you can just use it with the default jersey dependencies. Note that on a too long connection where no data is transmitted network equipment like firewall can close the TCP connection.
Server-Sent Events is a specification that allows the server to send messages on the same TCP connection.
Client use javascript EventSource to get a resource
Then the server can send at some point in time a payload, a message.
Then another
And so on
The connection can be closed programmatically at any time by either the client or the server.
SSE is not part of JAX-RS, so you need to have the Jersey SSE module in your classpath (additionaly in earlier version of Jersey 2 you had to programmatically enable the SseFeature).
Other things to consider :
SSE does not allow to pass custom headers, so no Authorisation header. It's possible to use the URL query string, but if you're not on HTTPS this a security issue.
SSE does allow to POST data, so this might go in the URL query string
Connection can close due to network (equipment failing, firewall, phone not in covered area, etc.)
In my opinion websockets are more flexible than SSE, and they even allow the client to send multiple messages. But Jersey does not implement the JEE specification that support websocket (JSR 356).
But really you should read the documentation of their SSE implementation, their's additional info like what is polling and what web-sockets.
AsyncResponse is like an ajax polling with long waiting time. The client initiate a single AJAX request to check for updates that will not return until it receives data or a timeout occurs and trigger another request. It does create unnecessary checking loop (at the server side) and the load is equivalent to the number of client connected. More client, more loop initiated = more resources needed.
Server-Sent Events is somewhat similar to long-polling at the server side, both uses loop to check for update and trigger a response. The only difference is that long-polling will continuous send request (either after timeout or receive data) whereas SSE only need to initiate once. Thus SSE is more suitable for mobile application when you consider battery usage.
Websocket uses loop as well, but not only to check for updates; also to listen for new connections and upgrade the connections to WS/WSS after handshake. Unlike long-polling and SSE; where the load increases with the number of clients, websocket constantly running the loop like a daemon. In addition to the constant loop, the load adds on as more client are connected to the socket.
For example, if you are designing a web service for administrative purposes, server running on long-polling and SSE are allow to rest after office hour when no one is around, whereas websocket will continue to run, waiting for connection. And did I mention without proper authentication, anyone can create a client and connect to your websocket? Most of the time, authentication and refuse connection is not done at the handshaking part, but after the connection was made.
And should I continue on how to implement websocket on multiple tab?
I have Hostgator basic plan of dedicated server. When in Peak time the response time of my website goes very high for REST API and it does not respond properly within time the loader run for a long time and show The 500 status code, or Internal Server Error, means that server cannot process the request for an unknown reason.
When I hit the same API at night it send response immediately.
My server is with APACHE and web-services are build in core PHP.
I am implementing a software updating server by REST web service. It is designed to get an client upgrade "instructions" (not the file itself) by GET request to resource
/clients/{clientId}/upgrades?completed=false
Clients are designed to polls the resource in a 30 minutes interval. The resource returns status code 404 when no upgrades available and return the upgrade instructions if available. When a client upgrading is completed, client will report to server by a PUT request to
/clients/{clientId}/upgrades/{upgradeId}
with some status change.
Now, an upgrade connection control from server-side is needed, i.e., a maximum simultaneously upgrade connection limit.
I can add a field of "upgrading" status indicator to upgrade resources, change the indicator when /clients/{clientId}/upgrades is accessed, and calculating a "count of upgrades with upgrading==true" to find the connection number. Then return status code 404 to client if connection number limit is exceed. However, it do breaks the stateless principle of REST web service.
Any idea is welcomed. Thanks in advance.
You could require that a client make a successful PUT to the resource with a value requesting to start the upgrade, such as a status of "upgrading". Every time your server gets one of those values it will check the current total of clients it has approved. If there are resources left then it can return success which allows the client to proceed.
When the clients send their completion PUT requests then you can decrement the resource counter.