I'm using Java's OkHttp3 to send multiple POST requests to the same REST endpoint, which is a third party AWS server on the same region as mine. I need those requests to be processed as fast as possible (even 1ms counts).
Right now the only performance tips I'm applying are very basic: I'm using HTTP2 so the connection socket is reused and I'm sending the requests asynchronously so it doesn't wait for any response until all requests are sent.
What are other tips I should consider to improve the performance?
EDIT: In case this is important for any reason, I'm currently passing all params through the URL, the body of the requests is empty. I may pass them as part of the body but I arbitrarily decided not to.
OkHttp is a good choice for low-latency. Netty may be a better choice for high-concurrency, but that's not your use-case.
You may want to measure what happens when you disable gzip. You’ll need to remove the accept-encoding request header in a network interceptor. That might make things faster since but only because you're on a fast link.
One other thing to research is disabling Nagle’s algorithm. You'll need to call Socket.setTcpNoDelay() which you can do with a custom SocketFactory.
The next release of OkHttp will support unencrypted HTTP/2. If you're okay with this (it is almost always a bad idea), removing TLS might buy you a (small) gain. Be very careful here; plaintext comms are bad news.
Related
We have a spring-boot appplication with microservice architecture.
We have a separate service for Authentication which provides a JWT token signed with RS256 algorithm.This token is sent in every request from client to our main application server.
I have the public key for verifying the signature.
Now this JWT token is being sent in every API request from client side as most of our URLs are protected.
Is it a good idea to cache the already verified JWT token to prevent repeated verification process of same token on every API call from same user?
There can be good reasons to cache token validation results. I would only do it if necessary, since in memory validation is fast.
Sometimes, after validating the token and identifying the user, you may want to do a fairly expensive lookup of roles etc - and you don't want to do this on every single API request
If caching then store a SHA256 hash of the token - and set a time to live no greater than the token's exp claim, as Ankur indicates.
My post explores this topic further.
API Gateway solutions often use this pattern. For example, AWS API Gateway allows you to cache a policy document that is quickly looked up when the same token is next received.
You can cache the JWT token but you have to set the cache timeout which should be equivalent to token timeout.
The main purpose of JWT is that of not having server-side state
This means that the server will not store any information, nor will the session.
If you cache your JWT, then your server has State.
You may have trouble later when you wanna scale-up your application(have multiple instances) and you may also face some security issues.
If you insist on the stateful server, then it's better to use cache servers like Redis, And notice that the existent time (lifetime) of each row (each JWT) must equal to its expiry date.
By standards, it's not a good idea to cache JWT in your server(it's
not a good idea to make the server stateful)
This wouldn’t necessarily add security issues, but you need to make sure that your cache stores verified JWT data only for as long as that token is valid. Otherwise, you are gonna have problems terminating sessions. Additionally, I’d recommend using LRU caches for this reason, so that you don’t have to store tokens that are not actively used at this point in time.
#Mehrdad HosseinNejad claimed that caching tokens adds statefullness. However, I would not say it is a critical issue in this case, since other servers that have not cached JWT in memory can still verify the JWT. The issue with scaling up is that cache may grow too large and consume too much memory on each server. Once more, I don’t believe it is much of an issue either, if LRU cache is used with proper parameters. The final suggestion in his answer is to use Redis. While it could be a good advice, it might be a slight overkill, considering the additional network latency. In-memory caching is always going to be faster, no matter what. Having said that, Redis is an extremely viable solution, if you want to avoid individual servers re-doing verification, if another server has already done that.
I know it is very basic question but I need a solid answer to clear my thoughts on it.
I am sending user credentials, key etc in header part in POST method,
Is it a good way? if not then why?
It's a bad way of doing things like these since if somebody could intercept your request - they would get your credentials easily. Better to avoid or at least encrypt this kind of requests.
One of the most popular solutions nowadays is to use OAuth 2.0 (or even better - OpenID Connect). They will bring some complexity to your system but the cool thing about it is that your application doesn't have to deal with passwords at all. Everything is delegated to Authority Server. And there are a lot of the authorization servers ready to use, for instance Keycloak (we have been using it and it and it was really good experience for us)
I have built a multi threaded web crawler which makes requests to fetch the web pages from corresponding servers. As it is multi threaded it can make overburden a server. Due to which server can block the crawler(politeness).
I just want to add functionality of minimum delay between consequtive request to same server. Whether storing minimum delay from robot.txt from each server(domain) into a HashMap and comparing it to last timing of request made to that particular server will be all right?
What if no delay is specified in robot.txt ?
The defacto standard robots.txt file format doesn't specify a delay between requests. It is a non-standard extension.
The absence of a "Crawl-delay" directive does not mean that you are free to hammer the server as hard as you like.
Whether storing minimum delay from robot.txt from each server(domain) into a HashMap and comparing it to last timing of request made to that particular server will be all right?
That is not sufficient. You also need to implement a minimum time between requests for cases where the robots.txt doesn't use the non-standard directive. And you should also respect "Retry-After" headers in 503 responses.
Ideally you should also pay attention to the time taken to respond to a request. A slow response is potential indication of congestion or server overload, and a site admin is more likely to block your crawler if it is perceived to be the cause of congestion.
I use 0.5 seconds as delay on my web crawler. Use that as default, and if it is specified you should use that.
I am designing my first GAE app and obviously need to use HTTPS for the login functionality (can't be sending my User's UIDs and passwords in cleartext!).
But I'm confused/nervous about how to handle requests after the initial login. The way I see it, I have 2 strategies:
Use HTTPS for everything
Switch back from HTTPS (for login) to plain ole' HTTP
The first option is more secure, but might introduce performance overhead (?) and possibly send my service bill through the roof. The second option is quicker and easier, but less secure.
The other factor here is that this would be a "single-page app" (using GWT), and certain sections of the UI will be able to accept payment and will require the secure transmission of financial data. So some AJAX requests could be HTTP, but others must be HTTPS.
So I ask:
GAE has a nifty table explaining incoming/outgoing bandwidth resources, but never concretely defines how much I/O bandwidth can be dedicated for HTTPS. Does anybody know the restrictions here? I'm planning on using "Billing Enabled" and paying a little bit for the app (and for higher resource limits).
Is it possible to have a GWT/single-page app where some portions of the UI use HTTP while others utilize HTTPS? Or is it "all or nothing"?
Is there any real performance overheard to utilizing an all-HTTPS strategy?
Understanding these will help me decide between a HTTP/S hybrid solution, or a pure HTTPS solution. Thanks in advance!
If you start mixing http and https request you are as secure as you would be using http, because any http request can be intercepted and can introduce possible XSS attacks.
If you are serious about your security read up on it, assuming that you only require https for sensible data and transmitting the rest with http will bring you in a lot of trouble.
You pay for http and https the same for incoming bandwidth and you should see any difference in instances hours. The only difference is the one time pay (per month) that you need to pay for SNI or VIP
Hi
I'm working on an application with Java as it's server-side language and for the client-side I'm using Ajax.
But I'm fairly new to ajax applications so I needed some opinions on the issue I've faced.
I'm using Spring Security for my authentication and authorization services and by reading spring forums I've managed to integrate Spring Security with Ajax application in a way that ajax requests can be intercepted and relevant action be taken.
Here's the issue: What is the best way to let the ajax application know that an error has occurred back at server. What I've been doing so far is that by convention I make random http 500+ errors. e. g. to prompt for login I return 550, and 551 for other issue and so forth. But I think this is not the right approach to this. What is the best approach for dealing with this situation?
If standard HTTP error codes (eg 401 Unauthorized) are rich enough, use them. Best not to make up your own HTTP error codes, they're meant to be fixed. If you need more info to be returned, you should return a richer object in the response body (serialized as eg JSON or XML) and parse the object on the client side.
In my experience, making up your own HTTP error codes is not the best approach.
I've known client and server-side HTTP protocol stacks to treat non-standard HTTP status codes as protocol errors.
A non-standard code is likely to lead to confusing error messages if they end up being handled as non-AJAX responses.
Similarly, using the "reason phrase" part of the response can be problematic. Some server-side stacks won't let you set it, and some client-side stacks discard it.
My preferred way of reporting errors in response to an AJAX request is to send a standard code (e.g. 400 - BAD REQUEST) with an XML, JSON or plain text response body that gives details of the error. (Be sure to set the response content type header ...)
If this a bug in your application or a hack that you want to protect from, just return a generic access error. Don't give detail of the error on the client as it could be used by the hacker to better understand how to abuse your API. This would confuse normal users anyway.
If this is to be normal application behaviour, it might be better to be sure that you fail gracefully by allowing to retry later (if it make sence), reconnect or reauthenticate. You should at least recognise if it is a disconnected error or an insuffiscient rights error, and display a nice looking explanation to the user.