If you dont have a state - even for security using oauth2 / jwt for instance - you dont need to care much if speed is the same on all hosts but if not use what is called sticky session. The purpose is to maintain the connection if possible. Le 17 sept. 2015 07:05, "Arthur Portas" <[email protected]> a écrit :
> Hi, thanks for helping! > > Real time response should be under 10 ms and bandwith for clients is a > constraint since many clients operate in african countries with no > broadband. > > Normally FE would be decoupled(angular) exchanging messages in JSON. BE > in spring, with: > Presentation-MVC and microservices using polyglot persistence with PgSQL > and a graph database clustered (orientdb) > for static content i totally aggre with CDN and what i'm thinking is: > > If i have a load balancer(ngynx, whatever) how can i tell the client on > subsequent requests to hit the same previous TomEE instance? or since my > beans are stateless i should not care for 'conversational' states and > client shouls always describe what it wants on request message payload? > > Thanks > > 2015-09-17 7:44 GMT+01:00 Gurkan Erdogdu <[email protected]>: > >> Hello Arthur >> >> This topic is more than application server selection. You can use the >> best application server in the world but if your architecture (including >> scalability, security, failover etc. ) is not designed well from the >> beginning of your project, you may be in trouble. It is also very important >> to understant what you mean by “respond in real-time?” Real time respond in >> 1 ms, 10 secs, 150 ns ? >> >> You have to consider: >> >> - Web servers with HA in mind (for HTML, CSS, JS static delivery, example >> : Nginx, Apache) >> - Using CDN (delivering your static contents, images etc. faster and also >> with no downtime) >> - Security from start (XSS attacks, DNS attacks etc.) >> - Clustered databases for scalable RW >> - Clustered application servers for failure, HA scenarios >> - In memory /distributed caches to cache mostly used stuff >> - Client side or server side rendering platforms (JSF or Angular JS with >> Bootstrap etc.) >> - WebSocket frameworks (if you use web sockets but it is not globally >> accepted standard yet) >> - Also, your architecture must allow you to scale your instances >> proportional to your application workload etc. >> >> As you see, there are lots of consideration to implement such a big >> system irrespective of the application server you use. >> >> Best. >> >> Gurkan Erdogdu >> Founder, ManageCat >> p. +1 (909) - 366 – 9337 >> a. 340 S Lemon Ave #7996 Walnut, CA 91789 >> w. http://managecat.com >> e [email protected] >> <http://twitter.com/gerdogdu> <https://tr.linkedin.com/in/gerdogdu> >> >> On 16 Sep 2015, at 23:20, Arthur Portas <[email protected]> >> wrote: >> >> Hi, >> >> to deal with a scenario like this: >> "develop a system capable of scaling to support the load of dozens of >> countries , and algorithms able to respond in real -time" >> what would be your suggestions to draw such a system architecture with >> TomEE? >> >> Love to hear our thoughts! >> >> Cheers, >> >> Arthur Portas >> >> >> >> >
