I whould like to know some opinions about OpenEJB: we are considering to use it on a new project, but really didn't found many opinions about it.
So, here is my question: how about it? Does it perform well? Is it stable enough for a production environment?
We switched to OpenEJB (deployed embedded in our app on Tomcat). Performance tests showed better or not worse results processing our transactions compared to JBoss (transactions include data access, JMS, and servlets). We use ActiveMQ within OpenEJB for JMS. There are no stability problems as of yet - we are still in staging (pre-production) environment though. The documentation is definitely lacking, but not as poor as other embedded choices. Overall, we consider this as a good choice if you run on Tomcat. Deploying it on other application servers turned out to be much more difficult (JBoss, Weblogic, Websphere) but there are not many reasons for this usually (we had few but dropped this after several attempts basically failed).
And as in all open source products: expect lack of support (documentation, troubleshooting, bugs, etc.) to be compensated by free access to sources.
We've had experience with Oracle OAS and JBOSS before. We decided to give OpenEJB a try. We've found out that it is not only very fast but it also much easier to setup and configure, and it has much better defaults.
Currently we implement our own failure measures in the client, so we don't know how they compare for clustering, or other advanced features that we don't use.
We we have to go back and deal with JBOSS in the developer side, we see a drop on productivity, because it takes too long to bootstrap.
Related
Has anyone done a thorough comparison of AppFabric and NCache or AppFabric and ScaleOut? We are currently looking to implement either AppFabric, NCache or ScaleOut for distributed caching in geographically distant locations and I would like to know anyone's thoughts who has compared them side by side. I appreciate that many people use one or the other and tell me why their chosen solution is great but I am really looking for a comparison of the two products. Such things as what does AppFabric not do or not do well (if anything), partially from a features point of view but also from developer's point of view. Is working with one compared to the other nicer, easier, more flexible, more powerful, etc.
There are plenty of lists of features which I can compare but am really looking for a comparison from someone who has perhaps been in a similar position to us and has performed the evaluation that we are about to launch into which will give us some food for thought whilst we do so.
Thanks in advance.
Here is a good comparison between the features of NCache and Appfabric
As a more mature product, NCache has a number of more advanced caching features that Velocity/AppFabric doesn't have -- check out their website for some "marketing" comparisons.
However, we have had a number of issues troubleshooting NCache and obtaining more visibility from their support/engineering team into certain behaviors of their application. Given that, plus the cost compared to AppFabric, I'm not sure I would recommend NCache at this point -- at least, we're in the process of re-evaluating our caching provider.
My frustration/complaint with Velocity/AppFabric is the the sluggishness in the release schedule. Seems like they were in CTP forever. Certainly Microsoft can crush NCache on price alone. There are now players like NorthScale (memcached) that are entering the fray which I think are also worth considering. A lot depends on what you want to use caching for in your application.
The most used one is Memcached. for sure.
we currently are starting using AppFabric as our dcache, as it easily integrates into our .net solutions, and has a good feature set, that we want to use.
if you just do basic dcaching, make a abstraction of caching itself (or use the .net 4 System.Runtime.Caching.ObjectCache) so you are safe if you want to do changes. or want to stress test more solutions.
Also, depending on your App architecture, think of using more entities/instances of your DCache, as different parts maybe favor different systems.
It is looking like we will need more advanced functionality than what Velocity provides so it will be either NCache or ScaleOut. There are good reasons for both, we just need to sort through these. We do not have Unix resources so memcached is out. I know there is a Windows port but colleagues who know memcached tell me that it is somewhat buggy and if you are going to bother going down the memcached path, you really should make the effort to go for the Unix version.
Some might argue that this is a biased comparison, but it's worth reviewing..
http://www.alachisoft.com/comparison/ncache-vs-appfabric.html
PDF has the full review.
http://www.alachisoft.com/downloads/comparison/ncache-vs-appfabric.pdf
Until recently I'd considered myself to be a pretty good web programmer (coming up for 10yrs commercial experience on a variety of e-commerce, static and enterprise applications). I'm self taught and have always used the Microsoft product stack (ASP, ASP.NET)...
My applications are always functional, relatively bug free, but have never been lightening quick. As a frequent web user I always found this to be the norm... how fast are the websites from the big tech players (eBay, Facebook, Microsoft, IBM, Dell, Telerik etc etc) - in truth none are particularly fast. I always attributed this to "the way things are with web apps"...
...then I cam across a product called Jira from atlasian and this has stopped me in my tracks...
This application is fast, and I mean blindingly fast.. too fast to time the switches between pages, fully live content, lots of images and data and cross references etc etc...
I run this on an intranet, with a large application DB, and this is running on a very normal server (single processor, SATA HDD, 8GB RAM).
Am I missing something?? Are my programming techniques that bad?? I am wondering if this speed gain is down to it being written in Java and running on Tomcat.
Does anyone have any benchmarks to compare JSP / ASP or Tomcat / IIS???
Thanks,
Mark
NOTE: this isn't a blatant plug for Jira. I don't work for them or have any affiliation to them... but I would like to be able to write applications like them :)
YMMV. But one of the longest-lived Things That Aren't True Anymore is the assertion that "Java Is Slow". Excepting floating-point (where most Java implementations aren't at liberty to use the floating-point hardware), Java is generally as fast or faster than compiled code. Some of the best and brightest have spent years of effort ensuring this, including such things as dynamic recompilation/re-optimization of code based on run-time metrics - something that statically-compiled languages like C or assembler cannot boast.
ASP is sort of the opposite extreme, since the original ASP had to recompile each page request each and every time it was made. ASPX addressed this by allowing retention of the compiled page code. That got rid of a lot of useless overhead.
A more compelling reason to prefer Java over ASPanything/IIS is freedom. A Java/Tomcat webapp will run under almost any OS on almost any hardware. IIS runs on Windows. Period. And for the most part, that also means Intel. Not Sparc, Not zSeries. Maybe you don't care. But then again, maybe next week IBM will offer your employer a can't-refuse deal on a mainframe.
I don't have benchmarks, and there are a lot of things that can make one platform preferable. But I permanently gave up on the "Java is slow" idea when I encountered the Poseidon UML tool with its cool real-time graphics UI and the FreeMind mindmapper tool. A small hit to startup the JVM, but after that, you'd never know what language you were working under.
The great debate. Java vs. .Net.
When .Net first came out there was an application written called "The Pet Shop." Which was a .Net port of Sun's J2EE reference application, "The Pet Store". It was announced that Microsoft's implementation was "faster."
As with anything, especially anything to do with marketing, you have to dig deeper to find the truth.
Any technology can be fast with enough hardware and the correct design.
In my experience there are two factors to speed: What type of hardware is used and how you architect your application (this includes database tuning).
Caching at various levels (response, db, etc.) makes a huge different in responsiveness of a web application. There is also a lot of things that are done to reduce time consuming operations like db connection pooling, sql statement caching, etc. As much as I'd like to say Java is better :-), I think in this case the performance is due to the way Jira was written and the fact that it's being run internally (probably with few users as compared to eBay, Facebook, Microsoft). This site, Stackoverflow, uses ASP.NET MVC and IIS and is very responsive and my guess (since code is not open sourced, yet) is that they use many of the same techniques you would find in Jira or any other web application built to scale.
I think that it is not typically the frameworks and languages used that make an application slow. In my experience, some frameworks like JSF or .NET server side controls give developers alot of freedom to make too many database calls and look things up too often, but that's definitely not the fault of the framework used.
Keep your application as light as possible and focus on keeping the data sent to the client as small as possible, and you will have a fast application. It's usually faster to develop fast applications too.
The Jira folks have written a best in class application (and charge for it) - nice work crocodile dundees.
I also suggest to consider also two aspects:
the maintenance activities: logging and deployment. In my opinion under a unix like server is more easier to log, deploy, and maintain new release than doing the same on a Windows server.
if the project require to use some open source application (i.e. Alfresco repository) Java is better solutions
People's opinion is mostly biased. Most people have never really tried the other while claiming the other is slower. I wouldn't trust any answer: it's mere opinion. It's boring to always read the same 4 cents again and again.
We have some performance problems with one of our applications. I thought about using something like dotTrace to find out where the problems are, but dotTrace would probably degrade performance even more.
What's the best way to profile an application that's on a prod environment w/o affecting performance too much?
The general answer is "don't do it".
Other than that, you can gain a lot by using performance counters. If the built-in counters don't help, you can create your own.
Among other things, the performance counters may give you an idea of how to reproduce the performance problems through load testing.
The next idea is to narrow down the area you're interested in. There's no sense impacting performance for the entire application if it turns out to be your web service access that's slow.
Next, be sure to have instrumented your application, preferably by using configuration. The Enterprise Library Logging Application Block is great for that, as it allows you to add the logging to your application, but have it configured off. Then, you can configure what kind of information to log, and where to log it to.
This gives you choices about how expensive the logging should be, from logging to the event log to logging to an XML file. And you can decided this all at runtime.
Finally, you're not going to be able to use dotTrace or something else that requires restarting IIS an adding code to your running application. Not in production. The ideas above are for the purpose of not needing to do so.
Profiling memory or cpu?
Memory: the best way would be to create a memory dump of the w3wp process (launch task manager, right click the process then "create dump"), then copy the dump to your local machine and analyse it with WinDbg. And look at which classes consume the most memory. There are lots of questions/answers here on Stackoverflow on how do do that (how to use WinDbg and analyse the .NET heap).
CPU: we use a short command-line profiler by Sam Saffron (woohoo, one of the creators of Stackoverflow!) His project is abandoned, but we forked it and maintain it here. https://github.com/jitbit/cpu-analyzer Everyone's welcome to contribute. It attaches to your threads using Microsoft's DbgManager and finds call-stacks that take longest time to execute.
Did you load-test the application on a number of sessions that's anywhere near the actual load of the production environment?
The first thing that comes to mind is that your app is not scaling well under load or that your db is not scaling well with an increase in size (causing this way problems even with a very limited number of concurrent sessions) but it could be anything really.
My suggestion is to replicate the production environment and run proper load-testing then look at the data and it'll give you some clue.
you don't wanna play games with your production environment, but if you don't have it already you could use logging to keep track of the sequence and time spans of key-events and take it from there.
You could use ants profiler
http://www.red-gate.com/products/ants_performance_profiler/index2.htm
They claim that "the overhead was hardly noticeable".
There is a 14 day free trial so you could give it a try.
Edit: I agree with John's comment, it will disrupt, require some down time, to get it started / stopped. Best to use it on a test environment to identify the bottle necks.
You can use ants profile as well as performance counter of the system. It will help you to determine whats the problem.
Here are some details about performance counter..
http://msdn.microsoft.com/en-us/library/fxk122b4.aspx
http://msdn.microsoft.com/en-us/library/ms979204.aspx
http://www.codeproject.com/KB/dotnet/perfcounter.aspx
I would recommend to take several memory dumps of the process in Production, look at all the stack traces and see if you find a pattern.
I am curious as to what others are using in this situation. I know a couple of the options that are out there like a memcached port or ScaleOutSoftware. The memcached ports don't seem to be actively worked on (correct me if I'm wrong). ScaleOutSoftware is too expensive for me (I don't doubt it is worth it). This is not to say that I don't want to hear about people using memcached or ScaleOutSoftware. I'm just stating what I "know" at this point.
So my question is basically this: for those of you ACTIVELY using distributed caching, what are you using, are you happy with it, and what should I look out for?
I am moving to two servers very soon...both will be at the same location. I use caching fairly heavily (but carefully) to reduce the load on my database server.
Edit: I downloaded Scaleout Software's solution. I've coded for it and it seems to work real well. I just have to decide if my wallet will part with the cash for it. :) Anyone have experiences good or bad with ScaleoutSoftware?
Edit Again: It's been a little while since I asked this? Any more thoughts on it? We ended up buying the solution from ScaleOutSoftware and have been happy with it, but I'm curious what others are doing.
Microsoft has a product pending code-named Velocity. It's still in CTP, and is moving slowly, but looks like it will be pretty good. We'll be beating it up in the near future to see how it handles what we want it to do (> 2 million read/writes per hour). Will post back with results.
There is a 100% native .NET, well documented open source (LGPL) project called Shared Cache. Looks like it is not yet mentioned on SO, but it's promising and should be able to do what most people expect from a distributed cache. It even supports different strategies like distributed or replicated caching etc.
I will update this post with more details as soon as I had a chance to try it on a real project.
We're currently using an incredibly simple cache that I wrote in a couple of hours, based on re-hosting the ASP.NET cache in a Windows Service (more info and source code here). I won't pretend it's anywhere near as optimised as something like Memcached but we were just looking for something simple and free until Velocity came along, and it's held up extremely well even under fairly heavy load.
It comes down to our personal preference for core components - i.e. ones that affect whether the site is available or not - that they are either (a) supported by a vendor with a history of rapid and high quality support, or (b) written by us so that if something goes wrong we can fix it quickly. Open source is all well and good, and indeed we do use some OSS, but if your site is offline then unfortunately newsgroups et al don't have a 1 hour SLA, and just because it's OSS doesn't mean you have the necessary understanding or ability to fix it yourself.
We are using the memcached port for Windows and we are very pleased with it. The enyim.com memcached client API is great and easy to work with. It's also open source, which is a big advantage, if you ask me.
We are now using this setup in a production web-app and it has helped a lot in improving its performance.
There's a great .NET wrapper/port found here on Codeplex. Awesomesauce!
We use memcached with the enyim library in a production environment (www.funda.nl). Works fine, very pleased with it, but we did notice a substantial raise in CPU use on the clients. Presumably due to the serializing/deserializing going on. We do around 1000 reads per second.
One tried and tested product by 100's of customers worldwide is NCache. Its
a feature rich product that lets you store session state in a redundant and highly available manner, lets you share data
within the enterprise as well as bridging for WAN communication essentially acting as a data fabric and lastly it lets you build an elastic caching tier so that when
your application scales, you can add servers to the cache and actually boost performance further.
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.