I have a standard web application deployed to an application server.
The application uses Struts 1, iBatis, JSP, Servlets, pretty basic stuff.
Now the application will be deployed to a Weblogic cluster. Is there anything in particular I need to rework so that the application may be deployed to a cluster, for instance, how about transactions?
Or is deploying to a cluster invisible to the developer?
Looking for general things to look into, things that for sure need to be done when a web application is deployed to a cluster.
I would recommend minimizing session data. Session data either forces a user to be "sticky" (once they use one particular server they have to keep going there) or the clustering software has to replicate all sessions to all servers.
Think hard about thread safety. You don't want a situation where one user can ever see another's private data.
Also look at you database isolation. You have to strike the right balance between serializable transactions and performance.
Related
I'm working on a Spring Boot application, using AbstractRoutingDatasource in order to provide multitenancy feature. New tenants can be added dynamically, and each one has it's own datasource and pool configuration, and everything is working well, since we only have around 10 tenants right now.
But I'm wondering: since the application is running on a docker container, with limit resources, as the number of tenants grows, also more and more threads will be allocated for each connection (considering a pool from 1 to 30 threads for each tenant) and the container, at some point (with 50 tenants, for example), will be killed due to memory limit defined at container startup.
It appears to me that, this multitenancy solution (using AbstractRoutingDatasource) is not suitable to an application designed to be containerized since I can't simply scale it horizontally to deal with more tenants.
Am I missing something? Should I be worried about that?
The point made in the post is about the system resource exhaustion that might arise with the increasing volume of requests as a result of increased tenants in the system. I would like to address few points
The whole infrastructure can be managed efficiently using ECS & AWS Fargate so that when there is a huge load, there are automatically new containers spun up to take the load. In case of having separate servers, ELB might be of help. There will be no issues when spinning up new containers / servers as your services are stateless
Regarding the number of active connections to a database from your application, you should profile your app and understand the DAP data access patterns. Any master data or static information should NOT be taken always from the database (Except for the 1st time), instead they should be cached. There are many managed cache services that can help you scale better.
In regards to the database, it is understood that tenants have their own databases, in case of a very large tenant, try to scale out the databases as well.
Focus on building the entire suite of features using async features in JAVA or using RxJava so that the async nature will help managing the threads.
Since you have not mentioned what cloud your applications will be deployed, I have cited sample using AWS. However most of the features can be used across Azure , GCP or AWS.
There are lot of strategies to scale, the right understanding of the business needs and data usage patterns etc... could help us decide the right approach.
Hope this clarifies.
We have four public websites running on the same database with different schema(Oracle). All of them are 'AAA' application and have "20,0000PV~500,000PV"daily. 90% data in websites are read-only and updated daily(By Batch). Less than 10% data, such as announcement, are updated manually. We are looking for the best practices to solve following concerns.
Improve website availability. Though we have a BCP database, it might need 1~2 hours to recover 4 websites in case database server is down.
Since most data are read-only, we are considering using in-memory db (hsqldb) or cache component(ehcache) to improve performance. As default, we are using ibatis and hibernate. Ehcache might not only be used on Level-2 cache, but also page cache.
We trends to build web services framework(restful) instead of java solution since mobile application might reuse them. Not very sure if it is a good idea to run website on web service on the same web application server. We have active-active HTTP and web servers.
On-line shopping is in the future plan.
Add database processes, make it at least 4 for serving each website.
Consider memcache
The same application server can run multiple applications. Not a problem it there is a good amount of RAM. However, if there is an overwhelm of users, you can always move particular applications to a different server. But, a better idea is to wait and see which service is worth that privilege.
Another web-application, too much of security and state management. Better put it in a new server.
What should we take care of before moving an application from a single Websphere Application Server to a Websphere cluster
This is my list from experience. It is not complete but should cover the most common problem areas:
Plan head the distributed session management configuration (ie. will you use memory-to-memory or database based replicaton). Make a notice that if you are still on 32-bit platform the resource requirement overhead from clustering might cause you instability issues if your application uses already lots of memory.
Make sure that everything you put into user sessions can be serialized with the default serializer (implements Serializable). You might otherwise run into problems with distributed sessions.
The same goes for everything you put into DynaCache. Make sure everything serializes properly.
Specify and make sure all the resource definitions (JDBC providers etc) will be made to a proper scope. I would usually recommend using the actual Cluster scope for everything that your applications installed to cluster use. That ensures the testing features work properly from proper points, and that you don't make conflicting definitions.
Make sure your application uses relative paths for resources in web interfaces. Once you start load balancing and stuff you can run into some serious problems if you have bolted down a lot of stuff.
If you had any sort of timers make sure they work well with clusters. With Quartz that means probably that you should use the JDBC store for timer tasks. With EJB Timers make sure you register the timers only once (it is possible to corrupt the timer database of WAS if you have several nodes attempting the registering at the exactly same time) and make sure you install them to Cluster scope.
Make sure you use the WAS provided SSO mechanisms. If you have a custom implementation please make sure it handles moving the user between servers in cluster well.
Keep it simple, depending on your requirements, try configuring your load balancer to use sticky sessions and not hold state in your HTTP Session. That way you don't need to use resource hungry in memory session replication.
Single Sign On isn't an issue for a single cluster as your HTTP clients will not be moving off the same http://server.acme.com/... host domain name.
Most of your testing should focus on database contention. If you have a highly transactional application (i.e. many writes to the same table) make sure you look at your database Isolation levels so that locks are not held unecessarily. Same goes for your transaction demarkaction. Keep transactions as brief as possible. If you dont have database skills yourself make sure you get a Database Analyst to help you monitor the database while you test.
Also a good advice to raise a PMR to IBM Support up front of any major changes, such as this one or upgrading to new versions etc. Raise it as a "Software Usage Question" and they can provide you with feedback from their knowledge database based on other customers input. Same would apply for any type of product which you have a support agreement for - ask support before problems occur.
Lets say you're starting a new web project that required the website to run on and MVC framework on Mono. A couple major requirements are that it has to scale easy, be stable and work with multiple servers that may or may not be in the same place or even on the same local network.
The first thing I thought of was a sort of cluster communication between servers. Each server would act as a node and be its own standalone application and would query other nodes in a known list for session information and things like that.
But one major design questions I have is should this functionality be built into the supporting framework or should the application handle the synchronization of the data?
Or am I just way off and this would never work?
Normaly clustering rather belongs to some kind of middleware layer, thus on your framework level. However it can also be implemented on the application level.
It depends on your exact use, if you want load balancing, scalability etc.
I would like to know any experience with the Tomcat Session Cluster solution. Is it production level? Does it scale? Can I use it in a server farm? Do you recommend any other solution for a session cluster? (Ex: database, terracota, jgroups, etc.)
Another alternative would be the memcached-session-manager, a session failover solution for tomcat: http://code.google.com/p/memcached-session-manager/
I created this project to get the best of performance and reliability and to be able to scale out by just adding more tomcat and memcached nodes.
Cheers,
Martin
From all the documentation I've read, it will work fine for a few number of instances but then become an issue.
We use Tomcat as our backend servers but design our applications to use as little session information as possible (basically just logins). Then we front the Tomcats with a load balancer like Apache or Nginx (the later which I'm favoring recently) and use sticky sessions. If a server goes offline (which is unlikely) then the user simply needs to login again, which depending on how you set it up could be transparent to them.
When I was looking to do more session based clustering, Terracotta looked very impressive. But stateless design makes scaling much easier.