I have to develop a web service that looks like this: I make a get call, including a string in the url, and I need to receive another string based on the initial string from the query.
I might have to make this call even for a thousands times a minute. Do you think that the server will be able to handle so much HTTP communication? Is a RPC approach better?
Any suggestion is welcomed, I am just starting to work on web services and I have no clue about the performance.
Thanks.
Thousands calls per minute means hundreds per second. I believe that modern computers can do more. I do not think that you will have serious performance limitations. But before you are starting check how long will it take to deal with the request. If this will take time I'd recommend you to decouple the HTTP WEB front end and business logic, i.e. process the request asynchronously. You can easily achieve this using JMS.
SOAP or REST? I personally prefer REST. It is simpler, it is faster. And it seems that you have only 2 String parameters, so SOAP does not give you any advantages.
IMHO, the main difference between SOAP and REST is that the former inserts an additional overhead (both processing and data) since it's data has to follow a somewhat strict structure. REST is simpler and leaner because it doesn't require you to explicitly define a message format, leaving this task to the software that will handle the message instead of the transport infrastructure.
So:
Do you want to enforce a message structure at the cost of additional overhead? Use SOAP;
You want a more lightweight option, at the cost of having senders and receivers piece together the messages into meaningful data? Use REST;
One of the key advantages of a REST web service is that its responses can be cached. In this way, the intermediate HTTP cache chain between your service and its clients bears a huge part of the total workload, so your web service can scale up. REST can be far more scalable than SOAP or RPC.
You may also want to check out Jersey at http://jersey.java.net/ as an alternative to Restlet.
Related
my project is created with Micro Service architecture, one business may need multiple services call. Currently, most of the services call need serial call, because the request of the next service call is generated from the last service call's response. This makes the invoke chain is very long, the performance is bad, is it any solution to deal with this scenario? Or I need to change my micro service design? Thanks!
You can try to solve part of your problem implementing a queue solution like an Apache Kafka, the first microservice process the data and post the data in the queue and the second microservice read from this queue.... process and post to another queue.
This approach can improve the performance because you can increase the numbers of partitions into Kafka, but you need to analyze what's you really need to process before sending the task to next service and if this can be paralyzed, if it can be paralyzed you can scale the microservice instances to process more data.
You have many options, but for microservices "talk" I recommend use queues.
Good luck with your project.
Hi i am using Spring 4 Async rest template to make 10k rest api calls to a web service. I have a method that creates the request object and a method that calls the web service. I am using Listenable Future classes and the two methods to create and call are enclosed in another method where the response is handled in future. Any useful links for such a task would be greatly helpful.
First, set up your testing environment.
Then benchmark what you have.
Then adjust your code and compare
(repeat as necessary).
Whatever you do, there is a cost associated with it. You need to be sure that your costs are measured and understood, every step of the way.
A simple Tomcat application might outperform a Spring application or be equivalent depending on what aspects of Spring's inversion of control are being leveraged. Using a Future might be fast or slow, depending on what it is being compared to. Using non-NIO might be faster or slower, depending on the implementation and the data being processed.
Best Architecture for implementing a WebService that takes requests from one side, save and enhance that and then call another service with new parameters.
is there any special Design Pattern for this?
There's not a lot to go on, but from what you've said it sounds like a job for "pipes and filters"!
To get a more precise answer, you might want to ask yourself some more detailed questions:
If you need to do any validation or transformation of the incoming message? Will you want to handle all requests the same way, or are there different types? Are the external services likely to change, and if so, will they do this frequently? What do you want to do if the final web service call fails (should you rollback the database record?)? How do you want to report failures/responses - do you need to report these back? Do you need a mechanism to track the progress of a particular request?
Since you are looking for a design pattern, I think you might want to compare the pros and cons of using microservices orchestration vs choreography in the context of your project.
If you do not need an immediate response to the calling system I would suggest to you to use event-driven approach if that's feasible. So instead of REST services, you will have a message broker and your services will be subscribed for certain events. This will hide your consumers behind the message broker which will make your system less coupled.
This can be implemented via Spring Cloud Stream, where you will have a Sink (microservice producing events, transformer - microservice that makes intermediate transformations possible and a source - microservice that receives a final result for further processing).
Another possible case could be Camel. It has basically all the integration patterns built in, so it should not be a problem to implement the solution either based on REST APIs or events.
I am building a web service in java. The business logic has no concurrency requirements. It is a simple rest call where an input json is expected and after some processing an output json is thrown back. However the request can be in millions where I am planning to bring in a load balancer.
My question is I have read a few articles which say that using akka will make the development faster and give a performance boost as well. Is this true in case of an application which has no concurrency requirement?
Thanks in advance.
Even without concurrency requirements, Akka is a great framework to use. You can use actors to encapsulate single responsibilities, send them messages to react on it and respond with another message.
This has the benefit that you can model errors inside your domain, which means, sending an Message with the error back to the sender, which can then decide how to deal with it, e.g. retrying n times. So you get a good exception modelling with Akka.
Even better, whenever an Actor fails with an Exception, the parent Actor can than decide, what to do, e.g. restart the actor, propagate the error even higher in the hierarchy etc.
So in conclusion, Akka helps you to develop a solid reactive domain based on messages. It also makes it easy for you to make it concurrent later, or to pass messages to other actors as well, when you logic changes.
I am sending REST based requests to a server. I would like to get the response as quickly as possible and would want to know the various optimizations that can be made.
One way is of course to send these requests in parallel in threads. What other options are available to optimize this?
On the server, part what configurations can be added?
Optimizations for REST calls (or just HTTP calls):
Like Brian Kelly said, cache the calls aggressively.
You can minimize the payloads that are returned when doing a GET. If it's returning JSON, you can trim the names of the fields to make the total return object smaller.
You can make sure you have compression turned on.
You can batch calls. So if a user wants to go three GETs in a row, you might batch those server side (assuming a web application) and then make one HTTP call with the three requests.
Again if it's a web application and you want to minimize load times for pages, you can load only essential data on page load and push the rest of the calls to AJAX calls.
You can optimize your database queries that serve the REST calls.
The biggest bang for you buck will definitely be caching though.