Designing, deploying, and managing a scalable E-commerce site with Windows DNA (1)--from m$

window| E-commerce | design | Scalable use of Windows DNA to design, deploy, and manage a scalable E-commerce web site

Today we're going to learn some of the best practices for scalability, usability, and reliability. We want to discuss load balancing and optimize your site, how to use Security Manager to protect your site, and how to analyze your site traffic. So we're going to have a lot of content today.

Our program is an overview of Windows DNA from a height of 50,000 meters. We want to talk about scalability and usability, how to optimize an E-commerce site, how to protect this e-commerce site, and finally, how to analyze the traffic on an E-commerce site. We also want to discuss UA Plus in this section.

The next slide is the Windows DNA expansion model. You will notice that we have an expression layer, a business logic layer, and a data layer. We have a small number of users in the presentation layer, who are your standard Internet users, as well as a large number of standard Visual Basic or other program language client-level users.

Notice that we're going from a large number of users to a small number of users, and this action is actually driven by Windows DNA. In the business logic layer, we put in all the business issues. And we're in the data tier, we have databases, legacy systems, and external applications.

So why do we come from a 2-tier system to a 3-tier system? Yes, first, the 2-tier system is poorly scaled, mainly because it has a large script. And it needs a separate server. It has a low performance and the script doesn't fit into a lot of code. It does not compress business logic and is not easily reused.

Now instead let's go to the 3-tier model, which is an ASP business application. Note that we have 3 layers, the first layer is ASP and HTML pages. This is our expression layer on the latest slide. It includes, usually, your UI (ie user interface), some simple data validation, along with ASP and HTML code.

In the second tier, the middle tier or the business logic layer, we have a business target layer. This includes your business rules and it consolidates your data through a variety of resources. That's what happened here.

At the last level, it is the data service layer, that is, the data integrity rules. It is important to know that it is not only a database management system, but also the functions of an e-mail system and various other external systems, which allows us to not be hindered by various restrictions on the 2-tier system.

Here is a business application tool that still uses ASP. We now have Internet Information Server, in our Active Activity Server Page layer, we will now display scripting language, VB Script or Java script and our Active Server Page layer, and then directly connect the commercial component layer, it is VB language , CC plus or java.

And then our last layer-the data layer, in this case, we use the sequel server. The question that comes up is why we use the 3 floor. We have discussed the limitations of the 2-tier system. The 3-tier system is ultimately scalable. It can be scaled to a variety of servers, such as a network font library. We can move the business component to a middle tier server. We can also move the data tier to a data server, which allows us to expand more and ultimately allow us to protect our systems in a more sophisticated way.

We now have reusable systems because all systems are component-based and we can use them over and over again. It can now be invoked either by ASP or by traditional clients, such as VB, C + +, office, and VB for the application.

Then the most important factor is that it is fully extensible, which means that we can use off-the-shelf components. We can use the third part of the component and we can finally build a regular component to use at this site or any other site we want to encounter.

We've talked a lot about scalability, high availability, but in fact only a few of us know what the two terms mean. So we're going to define them, scalability is the ability of an application to grow in size as the user demands. High availability is the ability of an application to continue to operate in the event of loss of a component.

The interesting thing about this is that most people can't remember that scalability can be vertical or horizontal, you can scale up or back up, depending on the load on a particular site.

When we talk about scalability and usability, what are we actually discussing about these two issues? Yes, in terms of usability, we're talking about hardware issues, operational and service issues, and then data and file management issues.

In scalability, we end up talking about vertical issues, zooming in or out, scaling problems, zooming to a server location, or structural problems. Maybe we will eventually move on to a larger server.

Some of the best habits are to consider scalability and high availability from the outset when you consider scalability and usability. When you start designing your site, remember to think about it from the beginning so that you don't have so many problems.

Hide your physical environment from the developer. Make the application portable. This greatly improves scalability/availability and ultimately improves security. Be sure to give security and these other issues to administrators, not developers, so that when you deal with scalability and usability issues, they don't compromise your security. And in the end, take advantage of your platform services so that you can use all the content that is built on the current win 2000 system.

This slide shows a good start for a standard ecommerce site. You will notice that we have two Web servers and one member server. You don't need to have two. We're just using this slide. All of these are finally stored on the same computer. But for this example, we say this is a good start.

We have LDAP, identity authentication, active user goals, content scheduling, and all business services in our web site. Instead, what we're going to do now is to use the next, mature application.

Now, in our mature applications, we expand content scheduling business services to a network location. This web site allows us to add services and servers as needed, so that we don't have to worry about changing the program. We are now being authenticated for the active user target in the MTS section. We also have other business objectives in the mainframe synthesis and maintain a framework or a legacy system in our host. We're going to get the sequel server from the basket or the basket. We get the sequel server from the product and get the LDAP service from a cluster of members.

Now, the interesting thing about it is that if you need it, you can finally add a good standard. You can use more LDAP or SNA Servers to have redundancy in the performance of your concerns. You need to be aware of performance in the future. You may want to disrupt these goals for a deeper understanding. This setting allows you to zoom in or even shrink it when you need it with some reorganization.

So, some of the horizontal scaling strategies are actually just repeating what we've discussed before, that is, IIS, you also need to move to a network location. NTS will be a network location in the IIS server. Separate MTS from your network location and load balancing for some business goals. The sequel component divides your database and provides your member components, partitioning the directory and using a dedicated LDAP service.

The high availability policy will once again use IIS, a network lot. Note that NTS will be the same as the previous slide but the results will bring together the hardware, operating system services that the server uses, and finally, Network Load Balancing. Having some spare time for data and membership, combining your servers and using multiple LDAP servers will give you high availability.

When we talk about high availability, we end up talking about load balancing in some way. Microsoft Network Load Balancing now allows us to load-balance our systems and license the availability we need.

Note that there is no single point about value now. If these nob hosts fail, we will still be able to run. There is no performance bottleneck and no additional hardware is required at this point.

It can, however, grow gradually as demand grows. We can rise to 32 window servers in a particular location, and eventually, if our two servers are broken, we can handle the transparency of planned and unplanned servers when they are not available. The scalability plan for it needs to be in our initial design. We need to make sure that we have business goals in them and you may remember that when you perform performance testing, you need to check your vertical section prototype, which means you need to create a prototype from the front end to the previous back end, as soon as possible in your product, so you can move forward and use a Web application like Strength testing tools Such emphasis tools are tested.

You must define your intended use plan, look forward to emphasizing the system and look at the patterns you expect, the different types of typical users, and their usage patterns. Build the script that the typical user expects to use. Masking users at your data level so you can prove your judgment is correct. The analysis is done from the second to the cross test.

You have to be sure that, as you go forward, you actually set your system to accept more content than you most importantly emphasize. So when you start to emphasize your site, you need to reuse the Web application Strength test tool to choreography, which is called Homer. You want to set breakpoints and behavior. Plan your flex path and remember to plan to empty out for 3-6 months so you can set any future extensions.

Determining a performance test is a task assigned in a group, not just someone who has a chance to take a look. You won't have so many problems if you can follow these points.

Now we come to the first demo, which tells us how to use the Web Application Strength test tool to test your site for scalability, usability, and reliability. OK, now we're going to move to the demo machine. In our first demo, we'll learn how to use

For the first time, we will open was, in the Start menu, program, Microsoft Web application strength test tool. And now, here we close the dialog box that creates the new script. The first thing we need to do now is to move the created sample folder when you install the Wal tool.

When you install the Web Application Strength test tool, you must remove it from a folder that is the folder that the Web Application Strength test tool is installed in, in the WWW root directory. We browse and copy and then move back to my inetpub/wwwroot directory and paste it into the virtual root directory. Close the window and now we're back in the Web Application Strength test tool.

We now look at the user interface for the was tool and we can look at the system. On the left, you will notice that we have a default node and a sample script node that will show all the scripts we currently have installed into the was database. These are the scripts that we built before and will be used later. We are using the sample script for the demo today. We'll recreate some of the scenarios in the sample script.

These are the scripts, say again, as soon as you install the WAS tool. Open this node for the sample script you can see the second comment below. When you click on the sample script, you will notice that it opens the detail section on the right, which shows us the specific choreography in the sample script itself, the specific features used by the Web application Strength test tool.

Each of these scripts emphasizes a feature of the site, cookie features, browser features, AB tests, identifier features, all of which are emphasized by this system. But before we get started, we'll make a copy of the sample script so we don't mess with the original script. Then we'll rename the test script. That way, we would not change these original scripts. I suggest moving forward as a practice so that you can always at least go back to the example. Most of the sample scripts are a base to use.

Next, we'll move on, we can make changes as needed, and here's the server name, and in this case we'll use a regional host because the Web application Strength Test tool is now in the same system.