I'm converting a Struts1 application to Struts2. As a beginning I only ported a few of the actions to see how they behave in Struts2. One of these actions serves an Ajax request sent by the clients once every second. In the current Struts1 implementation the request takes about 10-15 ms to execute, which I can see with Firebug. The Struts2 version now takes over 250 ms. I added the profiling interceptor to the action and I can see that most of this time is spent in setting up the execution of the action. The time spent in the interceptors is negligible.
Is it expected?
Thanks in advance for any help.
follwing the steps,
Turn off development mode using struts.dev="false";
Create your own default interceptorStack which specific to your project and remove unneccesary interceptors you are not using.
For further information refer the following link struts.apache.org/2.2.3/docs/performance-tuning.html
And you can find action execution time using timer interceptor so called timer.
And also i tried with JSTL, OGNL tags to compare the performance of jsp page rendering time. In my case OGNL has given best performance.
There are different aspects of benchmarking an application for the performance.The one mentioned by you seems very alarming as the difference is somewhat 25x.
Not sure what you mean by setting up the execution of the Action? so its really a bit hard to suggest any thing is particular.
We have like 9-10 S2 application and none of them have any performance issue as of now.
My suggestion is to use some profiling tool and get th information which specific block is causing an application to get slow, beside you can always follow the tips as suggest in other answer.
Which version of S2 are you using?
Related
I'd like to find redundant blocks of code in my service. Is there a way to check when that last time this code was used runtime? The service is running on GCP.
I don't think there's a great solution to your problem but you could instrument, perhaps via Aspect-Oriented Programming (AOP), selected places in your code with simple logging statements and then monitor those.
You should avoid including any "hot code" which is executed very frequently because you can slow down your service and produce an overwhelming amount of logs (harder to manage and costly).
There's a lot of way to do this, but personally, I would use logging into this function and then let this app running normally. Then, you'll just have to check you log files and check for your logging message occurrences.
However, I'm not sure if it is possible to get this information without any action of your part to see previous usages of your code block.
Let's start of by saying that I'm using version 3.1.2 of Axon Framework with tracking event processors enabled for both #EventHandlers and Sagas.
The current default behaviour for creating event processors for Sagas, as I'm seeing it, is to create a single tracking event processor for a single Saga. This works quite well on a microservice scale, but might turn out to be a problem in big monolithic applications which may implement a lot of Sagas. Since I'm writing such application, I want to have a better control over number of running threads, which in turn will give me better control over usage of database connection pool, context switching and memory usage. Ideally, I would like to have as many tracking event processors as CPU cores where each event processor executes multiple sagas and/or #EventHandlers.
I have already figured that I'm able to do that for #EventHandlers via either #ProcessingGroup annotation or EventHandlingConfiguration::assignHandlersMatching method, but SagaConfiguration does not seem to expose similar API. In fact, the most specific SagaConfiguration::trackingSagaManager method is hardcoded to create a new TrackingEventProcessor object, which makes me think what I'm trying to achieve is currently impossible. So here's my question: Is there some non-straightforward way that I'm missing which will let me execute multiple Sagas in the context of a single event processor?
I can confirm with you that it is (currently) not possible to have multiple Sagas be managed by a singleEventProcessor. Added to that, I'm doubting about the pro's and con's to doing so, as your scenario doesn't sound to weird at first glance.
I recommend to drop a feature request on the AxonFramework GitHub page. That way we (1) document this idea/desire and (2) have a good place to discuss whether to implement this or not.
Here is the summary: I need to build a simple java web app that, among other things, will let the user create, update, delete, and view records from a few tables.
My app is required to use Struts2 and the struts2-jquery-plugin to implement AJAX functionality (grid).
However, I'm new to Struts2 (and Java in general), so I've being trying to follow tutorials all over the globe. And the more I search, the more I find different solutions and plugin dependencies which means more tutorials to read. I've written everything from business, dao, and beans but the .jsp's and actions. I'm now short on time and can't spend another week on wrong directions. Hope this thread can save someone else time too.
Questions:
1- I've downloaded the showcase examples and they all seem to use hibernate plugin. Is it a MUST or can I use grid without it? Because it's too much info for a single human head at this point.
2- Related to sessions. Do I need to configure an interceptor to be loaded at every action call to check if user is logged in, or is there anything taking care of this by default in Struts2? I'm trying to avoid struts.xml, so I'm using convention. How can I achieve this session check without xml configs?
3- If anyone can provide some short and fast examples of using struts2 and grid, it'd be really appreciated.
More questions should come shortly.
My 2 cents: always use KISS (Keep It Simple, Stupid) pattern, especially if you are new to Struts2, JSP and Java in general...
I recommend to start with little things. Login Action, First Action, First JSP.
When all works (you can read data from DB through First Action and display it on First JSP), you can go deeper (EJBs, Interceptors, Validation, etc).
By the way, for Session Checking Interceptor, take a look here
(You put a boolean on login page, you check it from the Interceptor, then you can forget about it, instead of checking it on every Action...)
Aside from adding a custom timer to measure the beginning and end of a controller's action, is there an easier or more helpful way to show how long a page is really loaded (i.e. show at the bottom of the page: this page is generated in 30.5 seconds)? Note that in Grails, there's the concept of taglibs wherein you can add additional logic after all the processing done in the controller.
I'm actually not yet sure on how controller and taglib works or how the whole page is rendered in Grails, perhaps they are processed in parallel? Feel free to enlighten me on this too.
Thanks!
If you just want the times spent on the action and to render your gsp (with all its tags), you can use a simple filter to measure that. Take a look at this blogpost: Profiling web requests in your Grails application (disclaimer: I'm the author)
Regards,
Deluan
there are several ways to get the timing.
Easiest way is to configure your server to write logs with page generation time
you could inject your timing into for instance a security filter and the end of your page - but as you already mentioned, even this would mean to reinvent the wheel
have you checked the plugins?
debug plugin gives you timing info on the console http://www.grails.org/plugin/debug
perf4j also helps to profile your pages http://www.grails.org/plugin/perf4j
but if you want to present the timing to your users, I would suggest to download the debug plugin, unzip it and check where the timing is measured. You can easily copy this code and use it to output the timing on the page.
I used Spring Insight with STS. That's absolutely awesome for Grails Application in developpement. Modifying a tomcat for use in poroduction make it a bit tricky though
But you can go down to the duration of each select from hibernate and you have timing metric in real time through the all stack of application
Not really what you asked for (sorry), but maybe of interest is the JavaMelody plugin for Grails:
The goal of JavaMelody is to monitor
Java or Java EE application servers in
QA and production environments. It is
not a tool to simulate requests from
users, it is a tool to measure and
calculate statistics on real operation
of an application depending on the
usage of the application by users.
Not tried it myself, but it looks useful
My team is using the "cmt-timeout-in-seconds" setting, in the "sun-ejb-jar.xml" file on a GlassFish 2.x server, to control the transaction timeout threshold for an EJB module.
I realize that this is a pretty broad question... but we're having issues (I'm not sure of all the details myself), and I've been asked to verify that the "cmt-timeout-in-seconds" actually is being used.
Does anyone know of a way to interrogate or determine this from the application server, short of writing new custom code to test it? I'm not even certain what kind of custom code I would write if I had to go down that path.
It seems that the most straightforward answer is simply to write a small test case. I just created a simple EJB, with a custom CMT timeout setting in "sun-ejb-jar.xml".
I then wrote a method on this EJB class, annotated to require its own new transaction. This method did three things: (1) write a log message, (2) use Thread.sleep() to pause execution for awhile, and (3) write a second log message.
By using sleep values that were greater than or less than the CMT timeout setting, I was able to confirm that the settings were being applied.
However, one interesting note that I learned from this... when a container-managed transaction times-out for an EJB3 method, it does not interrupt or halt the execution of that method! The method continues to execute (or stays hung), and the consequences of the timeout are not handled and logged until after the method returns. Interesting behavior, which can lead to some serious bugs if you're not aware of it. See this article for more detail.