Have Geek Brain

The commercial issue of website architecture

I need to write an example using architecture, but there are some things I don't know, so I would like some pointers on the following:

The website must handle 5k concurrent users. The backend consists of commercial software, some web services, message queues, and a database.

I want to recommend using Spring for the backend, deal with various elements and expose some Rest services.

I also want to recommend wickets for the front (not here).

What I don't know: do I need to install front and back on the same tomcat server or two different ones? and I am tempted to put two servers for the front, with a load balancer (in this case there is no need for session replication). But if I have two front-end servers, do I have two back-servers? I don't want to create some kind of bottleneck.

Based on what I've read on on this blog , a really huge charge is the one-lump handling just for the first website mentioned. But I cannot find information on this, so I cannot say if it seems plausible.

If you can tell me about it, I can continue to study my case, that would be very helpful.

Thanks:)

+2


a source to share


3 answers


To expand on my comment, consider the typical process by which a client makes a request to your server:

  • it initiates a connection that has overhead for both the client and the server;
  • it makes one or more requests through this connection, keeping resources on the server for the entire duration of the connection;
  • it closes the connection, usually freeing up application resources, but usually still latching on the port number on your server for a number of seconds after the connection is closed.

So, when designing your architecture, you need to think about things like:

  • How many connections can you simultaneously open at the same time on your server? if you are using Tomcat or another standard server with one thread for each connection, you may have problems with 5000 simultaneous threads; (on the other hand, the NIO architecture can handle thousands of connections without having to use one thread for each connection); if you are in a shared environment, you may simply not have as many open connections;
  • if clients do not open their connections for the entire session, which is the right balance between the number of requests and / or time per connection, taking into account the overhead of creating and closing the connection (initializing an encrypted session, if necessary, network overhead when creating a connection , port "hogged" for a while after the connection is closed).


More generally, I would say, think:

  • in whatever architecture you go for, how easily can you redesign or replace certain components if they prove to be bottlenecks?
  • for each black box component / framework you use, what is the actual problem solving for you and what are its limitations? (Don't just use Tomcat, because your best boss mate told them so in the pub ...)

I also agree with what other people have said - you don't have to be too theoretical at some point. Build something sane, then run the test bed to see how it handles the expected amounts of data. (You may not have the entire application built-in, but you can start making predictions about "we're going to have X clients sending Y requests every Z minutes, and p% of those requests will take n milliseconds and write r rows to the database." ...)

+1


a source


There are probably two main reasons for having multiple servers for each tier; high availability and performance. If you don't do it for HA reasons, then the unfortunate answer is "dependent."



Having two front-end servers does not force you to have two back-end servers. Is the backend under heavy enough load that would require two servers? This will depend on what it is doing, and will show up best in load testing and / or profiling. However, for a site serving 5,000 concurrent users, I think yes ...

+5


a source


It depends entirely on your application. How hard are your sessions? (The wicket is known for putting a lot into the session). How heavy are your backend processes.

It might be better to come up with something that can scale. Load balancer with the ability to add new servers to scale.

Measuring is the best thing you can do. Create JMeter scripts and find out where your application crashes. Constructed a plan from there.

+2


a source






More articles:


All Articles