Currently we have a system that uses tomcat and it runs 3 wars that share number of connections. Problem that occurs is on high load in a single web app it affect the performance on other apps.
What i want to know is the following:
Is it better to run more tomcat instances where we separate web applications that are of "high priority"
Or is it possible to "spit" connections for each web app so lets say : 300 connections to app1, 50 to app2, 200 to app3 so they do not share connections.
Since i didn't tackle this i want to know what is the best solution performance wise.
Related
Is there any way to deploy two containers in just one app on heroku?
I have this question because I need to upload two Java applications to heroku, where I have a database configured in an app. These two applications, an API and a database update process need to access the same database.
If there is no way to upload two containers on heroku to solve this case, how would you do it? Having to upload a remote database, a process that updates that database based on a cron job and shell script and an API that accesses the updated database?
Would it be an option to have a single image with both applications and jobs?
It is possible to expose only one port on a Web Dyno therefore it is not possible to deploy 2 applications together if both require HTTP connectivity.
Option Web and Worker Dynos
The API processes the HTTP incoming traffic while the backend (DB) app runs in the background as worker: they communicate via a queue, for example RabbitQM, or you can use Redis (same concept: one app produces, the other consumes)
Option 2 Web Dynos
Deploy the 2 apps independently on 2 different web Dynos, then communicate over HTTPS using a secure token.
Option both apps in one Docker image
Although it is technically possible you won't find around much help (and consent) about it as it violates the Docker principles.
If you really want to give it a try I think you can start both apps (on different ports) and expose only the API one for incoming traffic.
I´m trying to get more familiar with Docker because everyone talks about it and everyone loves it. I know how Docker works in general, but I don´t understand how to used it in practice.
In my case, I have several web applications running on Tomcat. As far as I understand, it´s common to have one Docker container per application. But what does that mean in my case?
Should I have several containers each running Tomcat which in turn runs one web application? Or would I have only one container with Tomcat where all web applications are deployed on?
Understand why you will dockerise all your applications which are running in single tomcat instances ?
Lets say if your tomcat goes down then all your application will go down. So
Docker with microservices is the trend which tells a docker container should not have mutiple applications running i.e single resposibilty model.Avoid one container being responsible for multiple aspects of your overall application.
What will happen if you put all your applications in single docker ?
Availability : if container goes down all application will go down. Example : If you have ecommerce application and if offers service goes down then you should be able to do other stuff other that checking offers.
Deployment : If you need to deploy an application then all application will go down. for example : if you want to deploy offers update would it be correct to stop all running users which may be doing payments or other stuff?
Application Load and scaling :Lets say you have the modules, Payment, offers and shipping. I would expect the offer module will have more load than all others. So we can horizotal scale the offers service. But if we would have all application in single container then all application will be scaled which waste of resources.
Refer a nicely written nginx tech blog : https://www.nginx.com/blog/introduction-to-microservices/
Let me know if you have any questions more to ask. feel free to add comment.
Generally, it is better to run a Tomcat Docker Container for each .war app with filebeat or any other log shipping program in conjunction with single or fewer frontend containers. So 2 Frontend Web Containers for High Availability with 4 Tomcat Containers each serving a Tomcat app.
We have a single Tomcat app server and a single front-end web server running Apache and mod_jk. Is it possible for us to add a second front-end web server, that points to the same app server and also runs Apache and mod_jk?
We don't want to do this for reasons of load balancing. Rather, it's for reasons of migration. The new web server will be an entirely different OS and will use a different SSO authentication module. We want to be able to stage and test it, switch a DNS entry to make it live, and decommission the old server.
The current workers.properties file looks like this:
worker.list=worker1
worker.worker1.type=ajp13
worker.worker1.host=10.x.x.x
worker.worker1.port=8009
Can I just duplicate that config onto a second web server?
I have no experience or background whatsoever with any of this, but have been asked to assist with a server migration and am trying my best to help.
I have been reading the documentation for mod_jk and Tomcat. I have found all sorts of documentation on pointing a single mod_jk instance to multiple Tomcat app servers, but nothing describing the opposite of that, which is what I'm trying to accomplish?
Is this possible?
Edit: I should note that we do not have any access to the Tomcat server, as it is managed by a third-party vendor. I'm sure they'd make changes if we asked them, but we don't have the ability to log into it ourselves.
Yes - duplicating will be easiest. Most important** is keeping the worker name the same.
One gotcha is making sure Tomcat has enough connections available to be handled by both web servers. The normal defaults are typically high enough, but if you try to stress test, the tomcat server may need the sum of workers available on the webservers. But if you don't have enough, Tomcat does write a warning to the logs.
** Most important - Ok - Not that important since you are not using sticky sessions. But could be confusing later if you try this experiment with 2 tomcats when switching between web servers.
Yes, of course you can. I have done it several times, even just to change the static files served by Apache (js, images, css) and test the Tomcat application with a different "skin".
Usually when building a high availability system, not only the Tomcat's or any other back-end servers get replicated, the front-end Apache or IIS or whatever is used gets replicated too.
As you said, it should be fine just copying the workers.properties file and the mapping rules in the Apache httpd's *.conf files.
An also, check with tomcat management team that the incoming connections to Tomcat's AJP port are not limited by net rules or firewalls, making just the old Apache able to reach the Tomcat.
Can I just duplicate that config onto a second web server?
Yes sure, since you want to hit the same Tomcat server so you can simply copy your worker.properties from Apache instance 1 to Apache instance 2. If you have only those 4 properties then nothing but if you have some properties like worker.worker1.cachesize=10 or worker.worker1.cache_timeout=600 and you want to play around then change it. But bottom line is that since you want to hit same Tomcat instance so you can simply copy.
Understanding it in non-tomcat way - you can have more than 1 HTTP web server like Apache intercepting all the requests and then forwarding it to same application or web server. However this is not common because common thing is a web server load balancing the requests for back end application servers.
I have been reading the documentation for mod_jk and Tomcat. I have
found all sorts of documentation on pointing a single mod_jk instance
to multiple Tomcat app servers, but nothing describing the opposite of
that, which is what I'm trying to accomplish?
Is this possible?
You couldn't find in any of the reading because what you are trying is a corner case, generally people configure multiple Tomcat workers to serve servlets on behalf of a certain web server in order to achieve load balancing, virtual hosting etc.
You mentioned that you are doing all this in order to test the Apache running on different OS and using different SSO, I am assuming there is no hardware load balancer sitting in front of your web servers (Apache) so how you are gonna hit your new Apache? I think you need to do this explicitly because your current URL will be pointing your first Apache, so in order to hit second/new Apache you need to give your testers/users the URL containing end point (IP:port) of second/new Apache. Even if you are doing all this locally still you need to have your second Apache listening on different port, or may be different IP but that's not common.
I do understand that using the same tomcat instance for a number of web applications has some risks (e.g. if one web application crashes tomcat it will terminate the other web applications as well.). The benefit is of course cost effectiveness since one server is enough and having all the web applications in one place makes it very easy to administrate.
Are there any industry guidelines on how a good setup with multiple web applications on tomcat should look like?
Pros
One JVM to monitor
Common libraries can be shared (sometimes risky)
Cons
Common HTTP thread pool all applications are using (you can, however, configure several connectors with different thread pools)
One malfunctioning application can take down the whole server
Restarting one application requires restarting all of them (if not using hot-deployment)
You are right that hosting of multiple we applications on one application server / web container (either Tomcat or other) has benefits.
You mentioned the robustness issue when one application may cause failure of another. But let's simplify this: even if you have only one application you still want 24*7 availability. To achieve this goal people typically run more than one instance of application server with identical application on each one and load balancer in the enterence to the site. The same is relevant for several web applications. Just run N (2 as minimum) application servers with identical set of web applications deployed and load balancer. You will probably need a kind of watchdog that restarts server if it failed or if it stopped responding etc.
In some cases kind of clustering is required. But it is other story.
I've got a Java Enterprise Web Application which uses Tomcat6+Struts+Hibernate+MySql. at the time being it's publicly up and running on a single server. In order to performance issues we should move the application to a clustered environment. Anyhow I wanna use Tomcat6 clustering as below:
A Load Balancing machine including a web server (Apache+mod_proxy) as front-end
Some application server machines, each one running a tomcat6 instance
A session management back-end
And finally a db server
something like this
The load balancer machine receives all the requests and depending on the balancing algorithm redirects them to the respective tomacat6 machine. After doing the business part, the response is returned to the webserver and at the end to the user. In this scenario the front-end machine processes all the requests and responses so it'd be a bottleneck point in the application.
In Apache Tomcat clustering, is there a way to load balancing mechanism and web servers? I mean putting a load balancer in the front end and leave the request/response processing part to multiple web servers.
Tomcat has no support for clustering built in. What happens is that the load balancer distributes requests, so the various Tomcat instances don't need to know what is happening.
What you have to do is to make sure your application can handle it. For example, you must be aware that caches can be stale.
Say instance 1 has object X in it's cache and X is modified by a request processed on instance 2. The cache in instance 2 will be correct, the cache from instance 1 will be stale now.
The solution is to use a cache which supports clustering or disable caching for instances which can be modified. But that doesn't matter to Tomcat.