JSF performance limit [closed] - java

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a sort of unusual question, and I know it is a very controversial, but here it comes.
I have developed a few JSF applications in the past but these all limit the amount of users that can be servred about 5-6. This was partly because of a license based policy. I performed some tests with 20+ users and Selenium, and the applications went really slow. The problem was probably originating from the server's performance but still, I can't help to ask the following question:
Can a JSF application support a large number of users? My bet would be that the framework should allow it, however I can't think of any commercial website that uses JSF and can support thousands of users at a time. (If you could show me some that would be great!)
I ask this, because I have been asked to develop a larger system, and I would love to use JSF because I love it very much, however the recent performance tests gave me doubts. The lead programmer said it is only the server machine's perfomance that is the issue, but in that case, what kind of machine can support thousands of users logged in at the same time? The lead programmer is not the best of it's kind, that is why I want to hear a second opinion from SOF if you dont mind.
If there is any framework more suitable for extreme use please let me know which one it is, the only real constraint I have is that it should be Java based on the server side.
Again my apologies for the unconstructive question.

these all limit the amount of users that can be servred about 5-6
Not sure what the app's load or design are, but that sounds unbelievably low. JSF should be able to handle many 100s of users if designed right or even 1000s with the right infrastructure. JSF code runs with servlets and facelets - the framework is standard code on top of these, that has been optimized over time and gets JIT optimised at runtime.
E.g. With IBM Websphere Portal Server and Oracle Portal, the standard way to build customer portals and apps is via JSF. And they're used in massive installations.
Sounds like your past app(s) have some problem. I don't think you can blame that performance on JSF.

If you want an extreme number of connection is Java you might consider http://netty.io/ It is designed to support and has been tested for 100,000+ connections.
I suspect the bottleneck is not the number of connections you have but how efficient you serve up pages i.e. you JSF is particularly slow. If you optimise that I suspect you can handle more connections.

Related

JSF Performance: How scalable is JSF? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have yet to find a good benchmark on JSF performance. I know what you are thinking, it depends on your code/design/database setup, etc. I know that you have to optimize many things before you need to optimize your presentation layer (for instance you should see how good your database schema is), but let's say for the sake of the argument that we have reached the point in which we must review our presentation layer.
JSF is session-intensive. I've read a bunch of times that this can be a drawback when it comes to writing scalable applications. Having big user sessions in a clustered enviroment can be problematic. Is there any article on this? I'd hate to go to production just to see that the great JSF lifecycle and CDI integration have a huge cost in performance.
For high performance, session stickiness must be implemented, regardless of framework or language. How that's done depends on your setup; for example hardware loadbalancers usually have this feature. Then you don't really have to worry about inter-server network latency.
However, JSF+CDI performance on a single machine is also very important. Suppose the overhead is 300ms, that means a 4-core server can only handle 10 requests per second. Not too bad, but not in the high performance class. (Usually not a problem for companies on JEE bandwagons; they are usually enterprise-scaled, not internet-scaled; and they have cash to burn for lots of servers)
I don't really have the performance number though; it would be interesting if someone reports some CDI+JSF stats, for example, how long it takes to handle a typical page with a moderate size form.
I don't know if there is any truth in the assertion that JSF is heavy on session data. However, I'd have thought that the way to address scalability issues due to large amounts of session data would be to:
replicate the front-end servers (which you have to do anyway beyond a certain point of scaling), and
dispatch requests to the front-end based on the session token, so that the session data is likely to already be available in memory.
The presentation layer is one instance of an -> embarrassingly parallel application. In principle you can scale it by adding hardware; an extreme would be to have one hyper-thread per user in the minute of your site's maximum user-count. So scalablilty is not a problem here. What might be a problem is with pages that have to be rendered sequentially and take a long time to render even in single-user mode: If your JSF takes a minute to render in single-user mode then it will so too in multi-user mode and if you can not render it in multiple pieces in parallel then that is plain-old necessary.

Choosing between Django-Apache and Java-Tomcat for a web application [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In order to develop a web application that can easily scale, provide production stability, is easily deploy-able, and allows for fast development cycles, what points would you recommend I look at before choosing one or the other framework - using Java and Tomcat, or Django and Apache/Mod_WSGI?
Some pros and cons I could see immediately,
Tomcat apps are simple to deploy - drop a WAR file and you're done. Django apps seem to need more wrangling (Not sure if creating .egg files and dropping them in would work as well?)
Django's ORM seems much nicer than Hibernate - generates models directly compared to Hibernate's manual configuration files
Python as a language is faster to develop in, and much more concise than Java can be. (Of course, this is a relatively higher level discussion).
I've looked at Disqus's slides about scaling Django and am under no doubts it can be done. But would scaling a Django app be any harder than scaling a Java/Tomcat one?
I'm familiar with both Java and Python and the frameworks mentioned above, and it boils down to getting feedback those who've worked with either (or both) on scale.
Thanks!
Here are my experiences:
Django-Apache fits in 16MBs of memory, whereas Java-Tomcat requires much more than that.
Coding in Python is much faster, that is true. In Java, on the other hand, you have compile-time checks, profilers and debuggers that help you increase the stability of your application.
If you are planning to do heavy computations or need complex data structures, Java's compilation technologies will provide the speed you need.
It is easier to maintain a large project in a strictly object-oriented environment with advanced refactoring tools, such as Java.
Then again, coding in Python is much faster.
It's worth noting that Python code can be extended with C/C++ code. So Django applications can, in fact, be faster than their Java equivalents if one is careful to use native code where speed or complex data structures are required.
Obviously, my vote's for Django.
I choose Python with Django, because it is better in deployment. You don't need build war. You only copy files on server and that's all.
Django is easily scalable and production stable. see this.
If you prefer Java look at Grails. But it has 2 minuses: building war and a lot of memory usage(200 mb without users).

java vs python for GAE [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
from these links:-
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=java
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=python3&lang2=java
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=java
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=java
they appear clearly that the best choice for GAE is java, if scalable feature is what we are looking for.
my question is, What are the implications that will affect on performance if we use one of frameworks?
e.g.
django --> python
spring MVC --> java
slim3 --> java
... etc
Just a quick note - don't take this as a definitive/comprehensive comparison:
Both Django and Spring have a long startup time, which can lead to requests being dropped. I'd go with a framework that was speciffically made for GAE: tipify, slim3, etc..
I'm used both Python and Java on GAE, one project done using Python+Django, and one using Java/Groovy+Spring.
Python+Django is very easy to develop, initially, but not so easy to maintain. It have enough fast startup time, good documentation, atc.
Java+Spring requires more development (some parts takes 2-3 times more than doing same using django), have problems with startup time (even if you are using warmup requests). But it much more stable.
Python project have too much errors, mostly without any visible (to you) reason :( And it's very hard to find cause of this errors, because of dynamic nature of lang. And also, be ready to manually patch some libraries you're using. Don't get me wrong, i have many years of Python experience, but it's really hard to maintain it on such distributed systems like GAE, and it's really have problems with quality of code :(
Java, in other hand, works very well. In case when your code have problems, you'll see all information you need to fix this, and after few iterations you'll fix almost all bugs. Except one: sometimes you'll see startup errors :( Not too often, btw
PS btw, choosing right language for GAE depend on what language you knows betters :) If you don't know Java yet - don't start with it, it requires at least 1-2 years to understand language.
These benchmarks compare Python 3 to Java on a (presumably) standard setup. There's no indication of what sort of workload these benchmarks test, either.
App Engine runs Python 2.5, in a decidedly different configuration to what you'd find on a standard desktop, so the benchmarks really don't apply.
Further, scalability isn't about benchmarks like these - they make, at most, a constant factor difference. If your app is built to scale, it will scale in either language, to the same degree. Scalability depends on how well you architect your app and use the underlying infrastructure.
I would recommend using whatever language and framework you're most comfortable with - don't pick your language based on benchmarks.

Any real world experience with H2 database? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Has anybody out there got any real world experience with the H2 database? I'm interested in:
performance
stability
bugs
We use H2 as the storage engine for a very large RCP/Eclipse-based design tool. The tool itself has been in use for over 2 years now on some data-heavy projects so we've stressed H2 pretty thoroughly.
We did a fairly in-depth analysis of other Java embeddable db engines and chose H2. Overall I think we're pretty happy with it. We've had very few stability issues, but, as zvikico says, the development team is VERY responsive.
While the performance is good, sometimes you need to do some optimizations by hand. If you're used to working with enterprise-level databases that do a lot of this optimization for you, it may be a bit of a change. I'd recommend using the EXPLAIN command if you encounter a slow query to see what it's doing. Very often you can switch around the JOIN statements to force it to use indices more efficiently.
So, in short, thumbs up from me!
I'm using it as the base of nWire, which is an Eclipse plugin for Java code exploration. It is working in embedded mode as part of the Java process, not as a server.
Overall, it is very stable. I'm working with H2 for a long time now: I encountered some bugs in the early days, but that hasn't happened in some time now. The response of the developer has been great, too.
Regarding performance: it is very good. You can see the tests on the site. I didn't get a chance to compare it to other tools, but I'm very happy with it. In recent versions, it does tend to take a bit more time to open large databases, but that issue seems to be resolved, too.
Some other strong points:
Very simple distribution: just one JAR.
The embedded web console is very useful for quick access to the database. It proved to be a valuable development tool.
Responsive community support, especially from the development team.
I'm using H2 in some pretty heavy server applications with several millions of records. H2's performance is just phenomenal. As always, you need to think through your use of indices though. I was a long time user of MySQL before and have used several enterprise-class databases, but H2 is just smaller, faster and easier to use than the traditional heavyweights. It's also become our database of choice at Tynamo.org

any good books on scalable web applications (Java/Ajax/REST)? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Are there any good books on the subject worth reading and still up-to-date with current technologies?
I'm mostly interested in back-end architecture and things I should consider choosing clustering and database solution as I plan to use GWT for the front-end therefore won't be able to control a lot there.
I'm looking for a book which will answer questions like: How to choose load balancing strategy? What DB model to choose? How to scale data? How to scale request handling? What are common problems when building web application able to handle huge traffic?
About GWT: Google Web Toolkit Applications.
In general Even faster web sites performance and Building scalable web sites are very nice.
I have heard good words on The Art of Capicity Planning too, but i don't have it, so i cannot say from first-hand experience.
Check out O'Reilly's books. Here's one on High Performance Web Sites.
Don't know about books, but if you want information regarding real world, up to the bleeding edge, scalable web applications and architecture, then highscalability is a must read.
Perfomance Analysis for Java Web Sites by Stacey Joines et al?
My take is that Ajax doesn't fundamentally affect the overall approach to scalability. It may place even greater emphasis on the intelligent use of caching, but overall everything we knew about scalabilty remains true.

Categories

Resources