Review of “Performance comparison of dynamic web ... -

drivercutInternet και Εφαρμογές Web

13 Νοε 2013 (πριν από 7 χρόνια και 10 μήνες)

294 εμφανίσεις

Review of “Performance comparison of dynamic web platforms” By Apte et al. Reviewed by:- Abhra Maiti M.E., Computer Science & Automation (2009-2011), S.R. No.:- 4710-410-091-07154 Email:
Section-wise Summaries 1. Introduction  Processing delay is much more significant today than Network delay.  Four Technologies analysed: Java Servlets, JSP, CGI/C++, FastCGI/C++  Existing literature shows skewed results. Summary: This section introduces background for the paper. Two types of applications - one complex, one trivial – are chosen to perform varying situations for load-testing. It addresses the concerns of today's web servers delivering "rich" content. Since the web is an interactive platform, performance measurement is essential for a commendable performance. In this regard, appropriate choice of server implementation is essential. 2. Motivation  Application context: Building a Web-based messaging service.  Back-end: Used existing products; Front-end: one off-the-shelf product, one has been developed.  Use of Templates: Template Server interprets scripting-tags. Choice here: Java Servlets (powerful, feature-rich, easy-to use and deploy). Summary: Conducting a series of stress-tests. 3. Dynamic Web Platforms  A brief overview of the 4 technologies: CGI, FastCGI, Java Servlets, JSP.  CGI: A CGI program forks, getting inputs from the Web Server. Main problem - the traditional UNIX fork mechanism. First clone address space, then overwrite it.  FastCGI: Overcomes creation overheads by using Persistent processes. A dedicated process runs in a loop, waiting for requests. The web server creates a connection to this process whenever it needs a dynamic content, and severs it after the request has been serviced. Thus, process creation overhead has been removed.  Java Servlets: Servlet programs are used. A new Java "thread" is created (instead of a new process as in CGI) which handles the request. It sends the reply back to the web server via an API. Claimed to be fast since thread creation is more lightweight than process creation.  JSP: Uses servlet technology in a more efficient way. Rather than being part of the servlet code, "tags" are used. The servlet processes them, and replaces them with dynamic information. Summary: A brief overview. How the technologies evolved, what advantages they have over each other.
4. Testing Environment & Methodology  Used Template server programs - Using web templates to specify look-and-feel; uses tags for the benefit of the web-server.  Client-side measurements using Silk Performer. A 10 min. window was given. Average of response times was calculated. Unit of measurement: Session requests/time  Server-side measurements taken every 10s. Used to produce 10min averages.  Finding the bottleneck resources for each technology. 5. Results and comparison - Messaging Application  FastCGI is the clear winner.  Bottleneck possibilities:- CPU: CPU is not the bottleneck for Java technologies. A break-up of CPU times shows that CGI-based technologies spend most of their time in non-application system tasks like creating & maintaining processes/links. Java scores over them in system-time, but spends a lot of time in user-mode (by a factor of 5 over FastCGI). Memory: Memory bottleneck is tested using page fault as the parameter. Because of fork overhead, CGI shows the highest paging activity, while JSP & Servlets show much less. But still, throughput of CGI-based technologies is high, hence memory is not the bottleneck for Java-based technologies.  Only explanation: S/W bottlenecks inherent in Java technology are the ones hindering speed of user-mode execution. Summary: Java technologies increase response times even at peak CPU utilization. So, CPU is not the bottleneck for them. However, even though per-session-time increases steadily for CGI technologies, for CGI the corresponding throughput is roughly equal to the stable-condition values, indicating that for CGI it is the CPU that is the bottleneck. 6. Results and comparison - Trivial Application  Uses a trivial application - returning static HTML files.  Results are completely reversed - Servlets gives about 2.5 times the throughput of CGI; CPU utilization almost reaches full capacity for Servlet.  CGI spends all its time in paging - due to process creation overhead. Thus, Thrashing is what's causing CGI to slow down drastically. 7. Summary and Insights A brief technological insight has been provided as for the results. As for the Messaging Application, there are 3 layers of software support involved - Servlet interpreting Scripts, Java-Virtual-Machine(JVM) interpreting Servlet, Servlet running on OS. JVM contributes the non-CPU bottlenecks. JSP removes the first step, so is marginally faster. CGIs don't have the 2nd step, which reduces CPU time significantly. FastCGI is even faster due to use of a Persistent server program. Hence, it is perceived to be the best technology.
8. Conclusion Concluding, FastCGI looks better than others when it comes to complex applications, since Java software bottlenecks are not there. For simple applications though, JSP maybe the better option. It also says that performance may not be the only factor in choosing a technology in a real scenario. Some ease-of-use & performance compromises are often done. What I did not understand in the paper  Why was session-requests/sec. recorded instead of just requests/sec?  How were the CPU times broken up into system-time & user-mode time?  Since Java-based technologies involve 2-3 layers of software, won’t they have more memory activity always? Even in the trivial application, one process creation looks hardly the reason to outlast 3 layers of execution in case of Servlets & JSP. What I Liked about the paper  A first attempt at formally producing some tangible results about the performance of popular web-servers.  A two-pronged test, once complex and one simple, i.e., light application.  Break-up of execution time into system & user mode times. Helps in pin-pointing the bottleneck. What I did not like about the paper  Think time not considered.  Page generation engine written in Java Servlets. What is missing in the paper  Tests with Microsoft .NET technology. If I had to extend the work done in this paper what directions can I pursue?  Test new configurations with updated technologies, of maybe more complexity in interactions between one another.