I am working on a Java Web Application, using the following frameworks : Spring 3.1, JSF 2.1.26 and RichFaces 4.3.3.
The whole app is running in the Amazon Cloud under medium.m1 instances (2 - 2.4 Ghz single core), with a Tomcat 7.
My customer asked questions about the performances of the web application, and about the number of concurrent users that can be handled on the same server.
He gave me a report showing that a servlet with about the same hardware than the Amazon medium one is able to serve about 1000 requests per seconds (40KB page) :
https://www.webperformance.com/library/reports/windows_vs_linux_part1/
I took a classic page with header/footer, data table, sort/search/filters/data scroller... (80KB). I removed the database, the filters (security, etc., except JSF one) and kept 20 visible rows. Without any load, that page takes about 300 ms to be loaded.
When I executed the load test for my application, I realize that it can only serve 20 requests per second before the request/response time exceeds the 1000 ms.
Can you tell me if this is a normal behavior?
I can understand a JSF page is longer to build than a simple servlet one, but not being able to serve more than 20 requests, while the servlet can serve 1 000 is puzzling.
Is there any standard benchmark for a typical JSF application?
If you think I have optimization problem, can you tell me where I can search?
Thanks in advance for your answer!
In my personal opinion, you should take a look first at this article at JSF Central: Understanding JSF 2.0 Performance – Part 3 The code can be found On Github including the war files used in the comparison. There you can find a simple web application using JSF and the same application implemented in different web frameworks (Spring MVC with JSP or Thymeleaf, Tapestry, Wicket, Grails or plain Servlet with JSP).
The demo app has a simple stack using an in-memory database (HSQLDB) and JPA, so I think it should be pretty simple to deploy them on Amazon Cloud. That can give you a starting point about what can you expect from that environment and how you should set up your environment properly. Remember that in a complex system there are many elements that impacts performance, so you should evaluate later things like which params your persistence layer has and so on.
For JSF, it is known that Apache MyFaces will give you the best possible performance in all aspects, so if you can you should try with RichFaces + MyFaces combination.
Related
We have a ASP.NET MVC5 website hosted on Azure AppServices.
We have 2 distinct instances of this site on Azure: 1 for tests and 1 for production.
This 2 instances are in distinct Azure plans, but all services considered in each instance is in the same region (Western Europe).
The first one seems to work in an acceptable manner, but we are facing performance issues loading some pages on the 2nd one (sometimes from 15s to +30s page load times).
Each of our application instance is composed of:
ASP.NET MVC 5 (with FormsAuthentication)
N-Tiers Architecture
EntityFramework 6.1.3
ApplicationInsights service
2 SqlServer Databases (1 for business data & 1 for security data) located in a Azure Sql Service
The Azure plan used is "Basic (Small)" for AppServices, and "S0 Standard (10 DTUs)" for SqlServices.
The 1st one is running around 5% for CPU and 58% for Memory. The 2nd one is running around 3% for DTU.
With AppInsights, I've seen that "all is ok in controller" and the problem might comes from below.
I've also detected some page loads having the issue presents a failed Sql dependency call (with result code 207).
The Sql requests respond times are also separately ok (under 300ms).
We have, of course, already read a lot of posts about Azure performance issues but nothing that has helped us.
We would really appreciate some help please.
Many thanks!
Enable the profiler in Application Insights (same thing that used to live under https://azureserviceprofiler.com). It's now under the Performance blade.
Stress test your application for a few hours, enough for a good amount of ETL traces to be collected so it can paint a comprehensive picture of where time is being spent. A tiny "trace" icon will then become available next to your controllers:
Results look like this:
I'm aware of the hugely trafficked sites built in Django or Ruby On Rails. I'm considering one of these frameworks for an application that will be deployed on ONE box and used internally by a company. I'm a noob and I'm wondering how may concurrent users I can support with a response time of under 2 seconds.
Example box spec: Core i5, 8Gb Ram 2.3Ghz. Apache webserver. Postgres DB.
App overview: Simple CRUD operations. Small models of 10-20 fields probably <1K data per record. Relational database schema, around 20 tables.
Example usage scenario: 100 users making a CRUD request every 5 seconds (=20 requests per second). At the same time 2 users uploading a video and one background search process running to identify potentially related data entries.
1) Would a video upload process run outside the GIL once an initial request set it off uploading?
2) For the above system built in Django with the full stack deployed on the box described above, with the usage figures above, should I expect response times <2s? If so what would you estimate my maximum hits per second could be for response time <2s?
3) For the the same scenario with Ruby On Rails, could I expect response times of <2s?
4) Specifically with regards to response times at the above usage levels, would it be significantly better built in Java (play framework) due to JVM support for concurrent processing.
Many thanks
Duncan
Our team has been working with Grails (version 2.3.5) for a little under a year now, and the delivery team managing our servers has little to no experience related to applications written in Grails.
We have several Tomcat 7 instances, both in the test and production environments, with a certain amount of webapps. While some of the instances only containing webapps developed in Java (w/ Spring, Hibernate) sometimes get up to something like 20 contexts with no major issue, it seems like anything past 6 Grails applications (applications much similar to their Java counterparts) starts regularly causing the dreaded PermGen space issue.
The PermGen allocated is currently 536Mb, and the delivery team obviously suggests either using a separate instance for the new applications, or increasing the allocated memory; at the same time they are urging us to verify how these few apps are saturating the memory.
Our impression is that this is normal with Grails apps, but not having any senior Grails developer we have no way to confirm it from experience or better knowledge.
Is 536Mb too little allocated space in PermGen for 8 "regular" Grails webapps?
Update:
To specify what I mean by "regular", these are all couples of front-end + back-end for different services, where the front-end has nothing much more than a list of requests, a wizard to go from zero to a completed request, validates data, persists it, calls a webservice to get a protocol number, and in a couple cases calls an external payment gateway.
The back-end is used to manage requests and performs similar operations.
Every app has maybe around 20 entities with respective controllers, services, and views, and on top of that we have a few classes to handle security w/ Spring Security and an external infrastructure.
That's how it is. You have basically two options.
Migrate on Java 8 (see http://www.infoq.com/articles/Java-PERMGEN-Removed)
Increase the PermGen space further.
And a quick background. Unlike regular Java with Spring, Groovy and Grails generate quite a lot of classes in the runtime (GSPs being one example). Groovy also generate huge amount of classes itself - each closure is a class. All this put pressure on the permgen.
To ease off the pressure get rid of all unnecessary plugins, consolidate GSPs, rethink closures, use AOP only when absolutely needed etc.
We used to have similar problems, so our team started using one tomcat per app. We also separated credentials from security purposes. Now it's easier to manage them, monitor logs and make periodical updates.
Hint: it's easier (imho and cleaner) to train your admin in creating users, home_dirs with tomcats instances and just providing credentials.
Our rails app acts as a go-between for the UI and a java-powered API at the back. Basically, rails takes requests from the browser, tells the API what it needs, does some normalization and formatting, then hands it back to the browser. Our app is ALSO an installed app, often without internet access. Oh, and it all gets compiled into a JRuby war.
Currently, to get statuses of various things over time, we're running some javascript intervals every X seconds. We've started discussing a better solution to this, but given the requirements above, AND required support for IE9, I'm not sure what the best course of action is, or how to go about implementing it. Basically, I'm looking for some solid examples of either long polling in rails 3, or some kind of sockets implementation that will work for IE9 + our wonky installation/compiling requirement.
I'd appreciate any thoughts or feedback.
The IE 9 requirement rules out a WebSockets implementation.
Basically, I'm looking for some solid examples of either long polling in rails 3
An example for a long polling/polling solution is the MessageBus the Discourse forum software uses. It is a Rails app but they're not on Rails 3 any longer.
https://meta.discourse.org/t/why-does-discourse-not-use-web-sockets/18302
The "message bus" is component that allows us to easily publish information to our clients and between the rails processes in the farm.
https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/7
Message Bus is opinionated, it only supports the protocol it needs to drive Discourse. It only supports redis for storage. Message Bus does not support web sockets. It only supports polling and long polling.
I am developing my first site using Orchard 1.5 and I am concerned about the speed of the site. I realize that in development mode that pages are being compiled dynamically which will cause slowness, but I have done the following to set the site to production mode, and still, from page to page, each request is taking anywhere from 2 to 6 seconds to display. Here is what I have done:
Built the solution using a "Release" build
Logged out from the site (viewing as anonymous)
Set the application as the root site in IIS
Disabled the "Shape Tracing" module
Set the <compilation debug="false" ...> in the web.config
Set the theme to the base TheThemeMachine theme
I only have 5 pages of very basic content and the home page contains only the default content from the setup of Orchard. All pages are slow to load. Here is my site map:
Home (2 sec load)
About Us (2 sec load)
Bios (a projection page - 6 sec load)
John Doe (2 sec load)
Mary Jane (2 sec load)
With these settings in place, the page load times are still unacceptably slow. I am only testing this on my local machine and haven't rolled it out to the production server yet, but my machine is a robust quad-core machine, running Windows 7 with 8GB of RAM, so I don't see how it's much different than our production servers. Since all the requests are local, the network bandwidth is a non-issue. The only thing that would be different than in full production is that the application is accessing the SQL server on the network, but I can't imagine that there is that much SQL traffic.
FYI - I am checking the load time from FireBug and only using the value from the initial GET to the server and not any ancillary requests.
Is what I am seeing normal for an Orchard site, or what other changes should I make to optimize performance? When I go to www.orchardproject.net, it is very snappy (<300ms response) even with all their content, so why is my simple configuration so slow?
Why not run the Miniprofiler to measure where the slowdowns are before trying to optimize? You can get a module for Orchard to make it easy to plugin.
I've just added the Caching module to Our new site as well as added all pages to the performance settings page that is standard with 1.5, this helps a lot.
My site was getting progressively slower.. and I finally noticed that I had almost 50k comments! Most were marked as spam, but they were still filling up the database. I'm trying to clean them out now and will find out if this helps things or not (I'll update when I do)