Currently I try to improve the performance of my Play! application and i'm thinking about how to handle multiple instances (Scaleability) in future. The application should run with SSL.
Now I read: https://www.playframework.com/documentation/2.4.x/HTTPServer
It states:
Note that using a front end HTTP server will rarely give you better performance than using Play server directly. However, HTTP servers are very good at handling HTTPS, conditional GET requests and static assets, and many services assume a front end HTTP server is part of your architecture.
Does that mean that it would be a good idea to run the Play! app just as HTTP server (not HTTPS) and put a lighthttpd in front, configured for SSL, which acts as a proxy for the Play! app?
In very general yes, you can use frontend HTTP server for several purposes and minimize stress on your application, there's no reason to handle i.e. requests to static and public assets, as probably HTTP server will do it faster and/or better, that way your app will handle only traffic which is required to be handled by app.
Further, you can also use FE server as a load balancer and divide stress put on single app - to several instances even on separate machines.
Related
So I have this server where I host more than one website for professional purposes. But I also like to develop game websites and I would like to create a roguelike game with HTML5.
The game engine itself would be developped in C++ on the server and the client should ask the server what changes in the environment after every move.
So, normally, I would send an ajax request to the server where apache would reroute the request to my C++ application which is running as a FastCGI Service. My C++ application would check the session, look up if the movement is valid, change the internal values so that the character moves, also changes other things in the environment, and would then send the changes back to the client.
But ajax requests can be relatively slow, opening and closing connections all the time. So when I read about websockets, I thought I was in heaven until I saw that it will interfere with Apache and Apache is not really optimized to work with it.
Obviously, I could create a web socket on a different port, but with all those firewalls out there, I don't think that's a good option.
So, is there a way to combine the two? Where apache is able to understand that a websocket request should be ignored and passed on to my application instead?
I think it's pretty common to use nginx to proxy connections to ExpressJS, so all is done through ExpressJS.
I was thinking, why not use nginx to server the application since it's more simple to setup things like rewrites and let ExpressJS as backend only and then the application communicate to ExpressJS directly on 3000 port.
Is it a bad idea? If not, how often people does this ?
It's very common. But having your front end code directly talk to the node server adds complexity.
You have to handle CORS issues on the node server, including preventing cross site form submissions. See here Properly Understanding CORS with Same Host / Different Port & Security.
SSL is also going to be a bit more complicated. You'll need a wild card certificate.
However, there are some big advantages to using something like ngnix to host your assets. In addition to the ones you enumerated, it sets you up to go serverless. You can host your app out of an S3 bucket our through another content delivery network.
I was wondering if it would be okay to run Tomcat as both the web server and container? On the other hand, it seems that the right way to go about scaling your webapp is to use Apache HTTP listening on port 80 and connecting that to Tomcat listening on another port?
Are both ways acceptable? What is being used nowdays? Whats the prime difference? How do most major websites go about this?
Thanks.
Placing an Apache (or any other webserver) in front of your application server(s) (Tomcat) is a good thing for a number of reasons.
First consideration is about static resources and caching.
Tomcat will probably serve also a lot of static content, or even on dynamic content it will send some caching directives to browsers. However, each browser that hits your tomcat for the first time will cause tomcat to send the static file. Since processing a request is a bit more expensive in Tomcat than it is in Apache (because of Apache being super-optimized and exploiting very low level stuff not always available in Tomcat, because Tomcat extracting much more informations from the request than Apache needs etc...), it may be better for the static files to be server by Apache.
Since however configuring Apache to serve part of the content and Tomcat for the rest or the URL space is a daunting task, it is usually easier to have Tomcat serve everything with the right cache headers, and Apache in front of it capturing the content, serving it to the requiring browser, and caching it so that other browser hitting the same file will get served directly from Apache without even disturbing Tomcat.
Other than static files, also many dynamic stuff may not need to be updated every millisecond. For example, a json loaded by the homepage that tells the user how much stuff is in your database, is an expensive query performed thousands of times that can safely be performed each hour or so without making your users angry. So, tomcat may serve the json with proper one hour caching directive, Apache will cache the json fragment and serve it to any browser requiring it for one hour. There are obviously a ton of other ways to implement it (a caching filter, a JPA cache that caches the query etc...), but sending proper cache headers and using Apache as a reverse proxy is quite easy, REST compliant and scales well.
Another consideration is load balancing. Apache comes with a nice load balancing module, that can help you scale your application on a number of Tomcat instances, supposed that your application can scale horizontally or run on a cluster.
A third consideration is about ulrs, headers etc.. From time to time you may need to change some urls, or remove or override some headers. For example, before a major update you may want to disable caching on browsers for some hours to avoid browsers keep using stale data (same as lowering the DNS TTL before switching servers), or move the old application on another url space, or rewrite old URLs to new ones when possible. While reconfiguring the servlets inside your web.xml files is possible, and filters can do wonders, if you are using a framework that interprets the URLs you may need to do a lot of work on your sitemap files or similar stuff.
Having Apache or another web server in front of Tomcat may help a lot changing only Apache configuration files with modules like mod_rewrite.
So, I always recommend having Apache httpd in front of Tomcat. The small overhead on connection handling is usually recovered thanks to caching of resources, and the additional configuration works is regained the first time you need to move URLs or handle some headers.
It depends on your network and how you wish to have security set up.
If you have a two-firewall DMZ, with applications deployed inside the second firewall, it makes sense to have an Apache or IIS instance in between the two firewalls to handle security and proxy calls into the app server. If it's acceptable to put the Tomcat instance in the DMZ you're free to do so. The only downside that I see is that you'll have to open a port in the second firewall to access a database inside. That might put the database at risk.
Another consideration is traffic. You don't say anything about traffic, sizing servers, and possible load balancing and clustering. A load balancer in front of a cluster of app servers is more likely to be kept inside the second firewall. The Tomcat instance is capable of handling traffic on its own, but there are always volume limitations depending on the hardware it's deployed on and what the application is doing with each request. It's almost impossible to give a yes or no answer without more detailed, application-specific information.
Search the site for "tomcat without apache" - it's been asked before. I voted to close before finding duplicates.
Perhaps I have the wrong product in mind for our needs -- but I want to know if I can use Application Request Routing (ARR) in IIS7 to load balance requests for our application tier.
We have a farm of web servers. Each will be running our MVC web application. We load balance these servers through our web application firewall and load balancing appliances. In turn, they will be make WCF calls to our application servers. It's these calls that I want to use ARR to manage.
However, after looking at ARR, it seems like it's all about rewriting URLs coming from the client. But that's not how our situation works. If a user browses to www.myapp.com/home/index, we will in turn be making WCF calls to services configured in the web.config to say myappservice.foo.local/home/GetInfo.
How do I configure for this scenario, or am I looking at the wrong product?
I am not really sure to understand your scenario, but if i understand correctly, I think you would be able to call your WCF sevice. If you dont need to keep the session on your call, just uncheck the client affinity checkbox in server affinity configuration.
Configure your load balance to Round Robin, or Least response time in the load balance interface and your request will suppose to be load balance.
If you got more that one ARR server, i suggest you to disable Shared configuration on your ARR, we get some problem with this features on the ARR server.
I agree with #Cedric, not sure if the question has been phrased as well as it could be?
What type of load balancing/distribution are you looking to achieve?
Are you looking to balance load? Distribute load to specific server farms based on request content? Some other function? A little more info here might help get a better answer.
Will ARR work with WCF?
Yes, but only with the HTTP bindings as far as I know (wsHttpBinding and basicHttpBinding).
I still imagine there being a hardware loadbalancer (or some other method) in front of your ARR servers.
Your web servers are going to act as clients of the application servers servicing your WCF requests. However, it appears as if your already going to a DNS name of myappservice.foo.local/home/GetInfo - if it resolves to a virtual ip your already getting loadbalancing of some kind?
Why not use your existing "load balancing appliances" to do the load balancing?
I could definitely imagine a hardware loadbalancer servicing requests for mayappservice.foo.local, which then resolves to a virtual ip backed by your ARR servers. Then conceivably your ARR servers could then further refine who services the request, maybe by some content of the request? Maybe map all /home requests to one group of servers and all /foo to another?
Pretty sure I muddied the waters a bit more! :) But I'm very curious for reasons for looking at ARR.
I have an HTTP server which is in our internal network and accessible only from inside it. I would like to put another server that would listen to an HTTPS port accessible from outside, and forward the requests to that HTTP server (and send back the responses via HTTPS). I know that there are several ways to do this with some programming involved (and I myself made a temporary solution with Tomcat and a very simple servlet I wrote), but is there a way to do the same just plugging parts already made (like Apache + modules)?
This is the sort of use-case that stunnel is designed for. There is a specific example of using stunnel to wrap an HTTP server.
You should consider whether this is really a good idea, though. Web applications designed for use inside a corporate firewall are often fairly lax about security. Merely encrypting the connections prevents casual eavesdropping, but does not secure the site. If an attacker finds your outward facing server and starts connecting to it, they can still try to find exploitable flaws in the web service (SQL injection, cross-site scripting, etc).
With Apache look into mod_proxy.
Apache 2.2 mod_proxy docs
Apache 2.0 mod_proxy docs