Trying to get better performance out of my Xpages applications. Reading Mastering Xpages 2Ed, blogs, installed Xpages Toolbox.
One application in particular is very slow. The user sets some configuration documents that the program then loads into sessionScope variables. I use these heavily for setting up the navigation in the app.
Chapter 19 has many useful tips about performance and I am reviewing them. One guides you to rely too heavily on sessionScope variable, but use viewScope or managed beans.
Why are sessionScope variables a drag on performance and what could I use to increase performance?
Also, I am trying to use the Toolbox to profile my app and find out where the bottlenecks are, but I just don't quite get it. Should I use the CPU Profiler or the BackendP Profiler?
Any help would be greatly appreciated.
I don't believe there's any real "performance" difference in the scopes - meaning the speed of pulling the data from the scope.
I used to use sessionScope all the time but now try to avoid it for other reasons. sessionScope is great for a shopping cart for instance but very bad for "application state or page state". I used to use sessionScope for different stuff and then someone would open the same app in a second tab and that would cause problems.
I've not really used the profiler much - but it's HIGH on my list. Personally I'm much more interested in the backend profiler because that should really tell me what's going on with my code - which is probably the easiest to change.
Howard just did a great performance session at the MWLug conference. You might want to find those slides. (Sorry don't have that handy) but I suspect you can find them through his company site: tlcc.com. Also, a while back there was a webinar on performance that you might find interesting. https://www.youtube.com/watch?v=OXXi6cvBxGw
You have to be careful about using sessionScope beans - they will hang around until sessions time out. I have written a little article about this based on my experience. Have a look and see if it explains well enough why - and what the alternatives are (short session timeout and keepalive functionality).
HTH
/John
Related
My team has been writing a dashboard application using Node.js, Twitter Boostrap, Mongo DB, and Mule for an ESB.
Recently an executive asked us to change our approach to a Portal/Portlet container like Liferay.
Some of us on the team have experience with Liferay, and we have pretty negative feelings about it. Dealing with things like full-page refreshes, portlet lifecycles, style and theming issues, and limited DBMS coverage are at the top of our list of complaints.
We see where our executive team is coming from. They have decided that they want to make the dashboard extensible and easy or easier to plug into for other groups.
Is there a solution out there which can balance the modern web expectations of users with the enterprise needs of IT professionals and executives concerned with building and extensible application with something like Liferay? Pluggable widgets are important here.
Node would obviously be our preference with something like Grails as a close second.
Thanks,
This question may not exactly be a good fit for StackOverflow's format, but I can offer some thoughts still.
If you want to stick your current platform, you need to figure exactly what features your executives want to get out of moving to a new platform. Are those features something you can build into your current platform? How much effort will that take compared to rewriting everything else? How effort will it take to learn a new skillset across your whole team? I'm sure your team can learn the new skills effectively but that still takes effort and there will be growing pains as your teams learns. If you can show to your executives that you can get the same features for a similar or less effort and that you can still have similar total cost of ownership, you can make a case to stay on your current platform.
Also I think you are underestimating what a Portlet container can do. I work mostly with WebSphere Portal so maybe thats why I think most of the pain points you mentioned really aren't that difficult to manage for me. Just because your container needs a particular DBMS to manage itself does not mean you can't use a separate DB for your custom data needs. JSR-286 introduced serveResource as a way to make AJAX easier to implement in portlets. In WebSphere Portal (don't know about Liferay), changing out the whole page content without a page reload might the most difficult on your list I'll admit though.
Modern doesn't have to mean bleeding-edge tech. And the large software products can still perform if you know how to use them right, just like any other tool.
Does SPMonitoreScope have any performance implication? I mean, can I leave the SPMonitored scope in production environment? or is it better practice to remove this from code?
Many Thanks,
Joseph,
Here's what MSDN says - http://msdn.microsoft.com/en-us/library/ff512758.aspx
Performance Considerations
Using SPMonitoredScope to wrap code has a very low performance hit. However, it should be noted that if a section of code wrapped by SPMonitoredScope were to contain a loop that performed a high number of iterations (for example, iterating through XML nodes that are returned by a SharePoint Foundation 2010 Web service), the call stack included on the Developer Dashboard could increase in size exponentially, making it difficult to decipher the information displayed.
Best Practices
A tip for the best and most effective use of SPMonitoredScope:
All calls to external components, such as custom databases, external Web services, and so on, should be wrapped with SPMonitoredScope. This will make it easier for administrators to identify them as points of failure, and to isolate the problem quickly.
Regards,
Nitin Rastogi
There is certainly a performance hit using monitored scopes. That being said, it's relatively small for the tyoe of work it does. Best practice is to switch it off on production environments unless you are investigating a specific issue.
Most of our Lotus Notes developers do not have XPages experiance. They are used to doing old style forms development.
We are designing a new Lotus Notes database application that is required to be used in disconnected (offline) mode.
Why would we use XPages in this application instead of using old forms based application? (Keep in mind the existing skill set, learning curve and disconnected feature requirements).
As David said there are many enhancements in Notes 8.5.3 which make the disconnected XPages experience much better. With the latest Upgrade Pack 1 you can even install a supported version of the extension library which allows very rich applications to be deployed. 8.5.3 UP1 works on non windows clients also.
Newbs
I really don't think there is any reason to consider using XPages for an application which will be used, even in part, off-line. Off-line support is just not there (8.5.1 and earlier, at least). And XPage applications are generally less coupled to the Notes client - meaning, you would have a harder time doing things like scripting replications, updating the notes.ini file, etc.
I do highly recommend use of XPages for any web-centric applications, as the development model id a vast improvement over Domino forms and pages. But for a disconnect app, I think you have a lot to lose and not much to gain.
Not sure this is still a relevant question based on timing, but as of Notes 8.5.1 XPages in The Notes Client was available. There are some quirks with it but it's much better in 8.5.3.
The big key really is... if the app is going to be local - use local data. Don't try to have a local app that hits server side data.
My 2 cents.
Your question has a number of discussion threads, but I'll try be as concise as possible. I am going to be presumptuous here and say, what you're really asking is "Should I try and do XPages for offline apps ?"
Currently, XPages offline capability is not supported, but there is some recent discussion and widgets leading in that direction that would indicate it is possible, however it is not a vendor supported solution.
Even if you could work offline, there is a learning curve and "keyboard mashing" exercise in working it out. If you're Notes client fleet is pre-release 8. I would recommend you stay with "old forms" development. I am not sure how much the Evolution Transformer by GBS would help you here. It's just been release after an extensive beta. This may take some short term pain out of the equation if constrained by time and money to deploy an offline Xpages application based on the discussion link above.
Each company that has invested in inhouse developed applications has a unique situation depending on business demands, budget, plain ol'tenaciousness etc. The Notes client is un-surpassed for economical application development effort for both connected and offline compatibility of apps. Weigh up your determining factors and the decision becomes easier to make.
The XPages learning curve in my guestimate is easily 3-6 months of re-tooling. It's faster if you have a mentor leading you through it.
HI,
We are in the process of evaluating the different technologies to implement our application. Our application is like forums which will get the millions of users every day. For example, this stackoverflow.com handles such a heavy user base without any problem.
My question is whether JSF is suitable framework to develop such a application. We will be using components like RichFaces on top of JSF to design the front end. I have seen few comments about jsf that it is slow compare to other technologies.
I am anticipating your suggestions and ideas for my work. I am Java developer and would prefer to select any of the Java framework. Please advise me.
I would say JSF is indeed a very good choice. If you're building an application that serves "millions of users", then more often than not the back-end architecture is much more important than the frond-end web framework.
As a rule of thumb, only a small percentage of the time that processing a complete requests takes is spent in the web framework. The majority of time is always in the DB and in IO. Get that right and you're basically there.
The advantages of JSF are many. It's very easy to work with and it's very popular. This means there are many books, articles, blogs and fora out there to help you. Additionally, it's relatively easier to find extra employees who already know JSF than it is to find people having experience with one of the less used web frameworks.
The fact that JSF is so popular also means there are lots of component libraries and extensions available for it. This overall makes your life a lot easier. It's always faster to use some existing component than building it from scratch.
If you are looking for a website like SO, then I'd suggest GWT. It is easy to work with, faster (relative to jsf), good ajax support, embeddable and doesn't have a steep learning curve especially when you are coming from an action based framework like struts etc.
Checkout its demo show case and also the real world implementations here.
If you are building a forum-like application, why not use an existing solution such as the software on which stackoverflow.com is built-on?
Perhaps not directly programming related, but definitely product / commercially related. And I can't find a dupe, so I thought I would ask.
I have had a bit of trouble trying to figure out what best to say to people who have called and asked for advice. The Microsoft message is a bit worrying - basically, be worried, lock up everything and hold on tight. Some of the people I have directed towards that route have objected because of what it does to their browsing experience.
The "go get Firefox" message seems to be going down a bit better. What is the real story and what is the best advice to give?
How much actual risk does it pose between now and when MS patches it?
Edit: here are the links that my community seem to be reading...
WSJ
NP
BBC
Switch to another browser, already.
Chrome and Firefox would be my first two choices. Firefox would probably be best for now, just because it has a longer history.
The only way to prevent this on IE is to follow Microsoft's workaround procedures, which will cause a huge headache for users.
Use Firefox
Use NoSript (if you want proper defence in depth). I can simply say 95+% of all client-side exploits requires JavaScript and 90% of the time these are loaded from a 3rd party website. Therefore switching FF and using NoScript is a really good solution.
How much actual risk does it pose
between now and when MS patches it?
If you look at 0days in IE there are bunch of them, and IE got the worst security track. Also it's one of the most targeted application for attackers because there is clear profit in it. Therefore using IE generally not a good idea.
If you have to use IE,
Use protected mode
Use the latest stable version
Keep your windows updated
Run it as least priviliged user
Use a process control and personal firewall application such as Comodo Firewall (process control application if you can use them right can solve many of these problems, but got a massive overhead in user)
Details of previous IE issues, there are lots of them!
http://secunia.com/advisories/product/11/?task=advisories (IE 6)
http://secunia.com/advisories/product/12366/?task=advisories (IE 7)
You can inform them to patch by following some workarounds but as you notice it's not going to save them on the long run.
Apart from switch browser, pay attention to the emergency patch - get it installed.