1

My current web app provides a service to clients on a single site. It is NOT eBay, but I will explain using eBay as an analagous service we can all understand.

A client sets up a page, and other peer users can go to the page, do business, and the site charges for the service, the trades done.

Currently my site is monolithic so does not scale well. All users sit on the same site, and run on the same database, pages hosted in site.

With a redesign for AspNetCore on the cards, I would like to design in some scalability.
I would like to make the selling page in the above example a "site", ie a distinct web application, and fire up such a web application on demand.

Identity Authentication and Authorization will be handled by a stand alone singleton server, issuing tokens (if you like, authenticating against Facebook instead, etc).

A selling client approaches a minimalist central site to set up a selling "page". The selling page, and associated database and app mechanics pertaining to that page are all hosted in a single web-app, which is run on an an elastic resource host (virtual server or docker instance). The page lifetime would be multiple days. The central site runs continuously.

AspNetCore is attractive because the "selling page" site becomes an exe that is spun up on demand.

I am not sure how to make the central site spawn the selling page site on demand. Ideally I would like to avoid marrying a service supplier like AWS or Azure. Would Docker make the app service agnostic? Am I even barking up the right tree?

3

It is not clear to me that putting each seller site on its own application is beneficial. In fact, I could see it causing major performance degradation, in addition to unneeded technical complexity. I surmise you want to go with this approach because it seems cool, not because it has any tangible performance benefit.

Now, giving each seller its own DB is likely more beneficial, and easier to implement. The same way you have a repository method to insert a new row, you can have a method that inserts new tables. You don't need to design a convoluted meta-base or anything; sqlserver, ect, already have all the functionality you need built in. Seller specific DBs afford many performance advantages, such as avoiding unneeded locking during transactions, limiting the number of rows in a single table, and allowing scaling out without costly synchronization concerns.

Your focus should be the following: 1. minimizing cross request app-server memory access. 2. Isolating distinct functionality.

If you do not store things in session memory, it becomes very easy to spin up an additional web-server when demand dictates.

The classic way to isolate distinct functionality is to have the webapp, batch jobs, and database running on different servers. More advanced options can include having a specific cert server to take care of encryption, large file/image servers for static content, or a sales-transaction server. Looking at the specifics of your application, you may find even more isolatable functionality.

  • Coolness - not a factor. The business model seems to fit isolating each client in their own app bubble, which also fits with scale-out ideas. I am still not sure how to spin up an app on demand, on 'elastic' resources (servers or docker type units), or route API requests to new instances. Thx for the response though. – Steve Hibbert Jun 7 '17 at 8:45
  • @SteveHibbert from a performance perspective, please tell me what you hope to gain from isolating each seller, and why. – TheCatWhisperer Jun 7 '17 at 14:44
  • My assumption (!) is that each spawned app for a seller gets it's own resource stack, so it has it's own memory space and tcp buffers, and as discussed, a dedicated database. The 'seller page' is actually a miniature electronic market, so making it responsive is the aim. Again, I am fishing around here to see how I should approach this, I am not saying I will even try this, but it seems like a sane scale out approach. – Steve Hibbert Jun 7 '17 at 15:25
  • Giving each seller page its own resource stack, ect, will not improve performance. Your server(s) can handle x requests, no matter how they are split. In fact, splitting them will reduce performance because now the server needs to poll that many more apps. And each app will have a certain amount of static overhead. Also, starting a process is very expensive. If you want to increase performance, this is the wrong place to look. Why would each seller having their own resource stack increase performance? Now, isolating each sellers database will help performance quite a bit. – TheCatWhisperer Jun 7 '17 at 15:51
  • 1
    Good points, I was simplistically looking at it as 'more=better'. Thanks for the explanation. – Steve Hibbert Jun 8 '17 at 9:45
1

There are two ways of scaling: scaling up (vertical) and scaling out (horizontal).

Scaling up involves getting a single machine to do more, e.g. by adding CPUs, or by architecting your software so that it only performs a very narrow range of functions.

Scaling out involves architecting your software so that it can be supported by multiple machines ("nodes") without any adverse impact on logic. For example, a series of 10 web servers running identical code may be used with a load balancer to increase your capacity tenfold.

Scaling out is generally superior because you can keep scaling forever (you can add 10, 20, 100 nodes). Vertical scaling generally is going to have a hard limit.

So in this spirit, I would suggest you abandon the idea of "one seller, one application" and instead put all sellers on one application, but design the application so that it can be run in a load-balanced environment on a number of machines. The basic steps for this are:

  1. Eliminate or control dependence on process-specific state (e.g. session variables held in-proc). You can do this by making your application stateless, offloading state to a a separate state server (e.g. AppFabric), or (in a pinch) by enforcing client stickiness.

  2. Database scaling tends to be the most difficult part due to the requirement for ACID. To get your web apps to scale out, you will want to reduce database load as much as possible.

  3. Develop for multitenancy so that sellers can safely coexist on the same application while retaining their logical independence.

  • Scaling out also fits the business model / problem domain well. Statelessness is a good goal. I guess if I use MS SQL I can use a SQL server cluster that will appear as a single server to the app, right? – Steve Hibbert Jun 7 '17 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.