Has the database server run out of resources, e.g., disk space or memory?
Is the database software running on the database server? Has the application’s account on the database server expired? Is the firewall port open between the web server and the database server? Is the load balancer on the web server running correctly?
Īre the application’s services running on the web server?. Is the web server having resource issues, i.e., disk space, memory, database connections? Is the DNS name being resolved correctly? Is the firewall port between the user and the web server open? Is the user’s network account in Active Directory enabled? Is the user’s application account enabled? Is the user correctly entering their ID and password? ĭoes the user have an account in the application?. Is the user entering the correct URL into the web browser? Some of these causes apply to both client-server and web-based applications: Here are just a few possible causes that you’ll have to investigate. On the other hand, troubleshooting access or performance problems can be more difficult due to the larger number of components and interconnections. Typically, you just have to add their account to the application and give them the URL to go to within their web browser. Bringing up a new user is easier because you don’t have to load software onto his or her PC. Some things are easier under a web-based application and some things are more difficult. Some are difficult to support, while others are significantly easier to work with. A lot of it depends on the applications themselves. Overall is it harder or easier to support a web-based application than a client-server application? It’s difficult to answer that question broadly. Chapter 15 provides information on tools that can be used to identify what firewall ports are open. Maintaining all of the rules in a firewall isn’t easy and periodically that team will make a mistake and your application might be impacted. įirewall and port issues can be frustrating because something that worked yesterday might be failing today. All of these combinations, along with the various options for configurations of settings of the O/S and browser, make it difficult to pin down exactly what the cause of a problem is. Users employ a wide variety of computers, operating systems, and Internet browsers. 
Chapter 24-“UNIX Tools” provides information on tools that you can use to determine if a problem is or isn’t being caused by network issues. Be sure you have some proof before blaming the network. It’s very easy to blame unknown performance issues on the network, but most of the time, it turns out to be something else. I will advise you that the chances of the problem being the network are fairly slim. If the network is disrupted or slowed down significantly, then the application will get very sluggish, very quickly. After you investigate it you’ll determine that they’re using Internet Explorer 10 or Opera or another unsupported server. You can tell users over and over that application XYZ is only certified for Internet Explorer 9, but I guarantee you that you’ll have complaints from users that the application isn’t working on their computers. For example, you have little control over what browser or version of browser each user has on their desktop. Many of these pieces are outside your control. Unless you’re extremely familiar with the application you won’t be aware of all the pieces involved. More pieces of software are involved for example, plug-ins, HTML, and Java script run behind the scenes to allow the application to function. The primary reasons for this is that the combined environment is more complicated that a traditional environment: Supporting a web-based application can be much more challenging than supporting a client-server application.
0 kommentar(er)
