we've got an application developed in java, with GWT providing the frontent. The application is used on a variety of hardware specifications, e.g. also on older machines. Of course users complain about performance.
We'd like to collect profiling data from real-world users. So far we can measure the pure server-side duration (that's easy) and the duration of the network roundtrip (not so easy, but we managed that).
The hardest part for us is measuring the time elapsed between "user clicking on search button" and "first xxx rows of grid have been displayed".
Any idea?
Thanks
Holger
I would play around with creating a timestamp at the start of the page load and a timestamp at the end. I believe that "the beginning" would be "onModuleLoad" and the end would be after your last element/widget is added. I hope I have given you a good idea of where to start. You can play with moving these timestamps around to mazimize the time difference that you get. Once you feel confident that you are getting the rendering time, you can save the time difference in a database so that whenever anyone uses your page you get more user data.
Try using SpeedTracer, it's a google chrome plugin developed by google itself
There is no full-stack solution at the moment as far as I know. What you could build internally is a combination of remote logging, gwt lightweight measurements and deferred binding magic.
The first part is to understand that all RPC events and initialization sequence are already measured and how to plug in into that: http://code.google.com/webtoolkit/doc/latest/DevGuideLightweightMetrics.html
The second part is adding Deferred Binding magic to measure onSuccess() method execution time of application Callbacks. The inspiration (but not a solution) could be found here: http://josephmarques.wordpress.com/2010/11/29/performance-monitoring-using-gwt/
The final part is delivering back to client. Here you may use gwt-log or new gwt logging possibilities. Not sure if they implemented that in JDK logging though.
I was thinking to create an embeddable open source library today as we have solved exactly the same problem recently and in process of porting that to GWT 2.0 :)
But I guess it will take some time from idea to implementation...
Hope it helps.
Dmitry
You can use the Duration class available on GWT Client side. com.google.gwt.core.client.Duration
It is a utility class for measuring elapsed time on the client side.
Example usage:
Duration duration = new Duration();
doSomething(); //Returns the number of milliseconds that have elapsed since this object was created.
GWT.log("time taken for doSomething() to complete: "+duration.elapsedMillis());
Documentation
More examples
Related
I've been testing Plaid's investments transactions endpoint (investments/transactions/get) in development.
I'm encountering issues with highly variable delays for data to be returned (following the product initialization with Link). Plaid states that it takes 1–2 minutes to return investment transaction data, but I've found that in practice, it can be up to several hours before the data is returned.
Anyone else using this endpoint and getting data returned within 1–2 minutes, or is it generally a longer wait?
If it is a longer wait, do you simply wait for the DEFAULT_UPDATE webhook before you retrieve the data?
So far, my experience with their investments/transactions/get has been problematic (missing transactions, product doesn't work as described in their docs, limited sandbox dataset, etc.) so I'm very interested in hearing from anyone with more experience with this endpoint.
Do you find this endpoint generally reliable, and the data provided to be usable, or have you had issues? I've not seen any issues with investments/holdings/get, so I'm hoping that my problems are unusual, and I just need to push through it.
I'm testing in development with my own brokerage accounts, so I know what the underlying transactions are compared to what Plaid is returning to me. My calls are set up correctly, and I can't get a helpful answer from Plaid support.
I took at look at the support issue and it does appear like the problem you're hitting is related to a bug (or two different bugs, in this case).
However, for posterity/anyone else reading this question, I looked it up and the general answer to the question is that the endpoint in the general case is pretty fast -- P95 latency for calling /investments/transactions/get is currently about 1 second (initial calls on an Item will be higher latency as they have more data to fetch and because they are blocked on Plaid's extracting the data for the Item for the first time -- hence the 1-2 minute guidance in the docs).
In addition, Investments updates at some major brokerages are scheduled to happen only overnight after market close, so there might be a delay of 12+ hours between making a trade and seeing that trade be returned by the API.
I have a question regarding the performance of RequestFactory and GWT. I have a Domain Entity with 8 fields that returns around 1000 EntityProxies. The time between the request fires and it responds is around 20 seconds. I do the same but returning 10 EntityProxies and the time is 17 seconds, almost the same.
Is this because I'm working in development mode, or when I release the code to the web the time will be the same?
Is there any way to improve the performance? , I'm only reading data so perhaps something that only read and doesn't writes may be the solution?
I read this post with something similar to my problem:
GWT Requestfactory performance suggestions
Thanks a lot.
PD: I read somewhere that one solution could be to create an xml in the server, send it to the client and recreate the object there, I don't want to do this because it would really change the design of my app.
Thank you all for the help, I realize now that perhaps using Request Factory to retrieve thousands of records was a mistake.
I initially used a Locator to override isLive() and Find() methods according to this post:
gwt-requestfactory-performance-suggestions
The response time was reduced to about 13 seconds, but it is still too high.
But I solved it easily. Instead of returning 1000+ Entities , I created a new database table which each field has all the same field records (1000+) concatenated by a separator (each db field has a length of about 10000 ) and I only have one record in the table with around 8 fields.
Something like this:
Field1 | Field2 | Field3
Field1val;Field1val;Field1val;....... | Field2val;Field2val;Field2val;...... | Field3val;Field3val;Field3val;......
I return that One record through RequestFactory to my client and it reduced the speed a lot!, around 1 second. I parse this large String in the client and the duration of that is about 500ms. So instead of wasting around 20 seconds now it takes around 1-2 seconds to accomplish the same.
By the way I am only displaying information, it is not necessary to Insert, Delete or Update records so this solution works for me.
Thought I could share this solution.
Performance Profiling and Fixing issues in GWT is tricky. Avoid all profiling in GWT Hosted mode. They do not mean anything useful.
You should profile only in WEB mode.
GWT RequestFactory by design is slower than GWT RPC and GWT JSON etc. This is a trade off w.r.t GWT RF ability to calculate delta and send only small amount information to server on save.
You should recheck you application design to avoid loading 1000's of proxies. RF is mean for "Form" like applications. The only reason you might need 1000's of proxies is for a Grid display. You probably can use paginated async grid in that scenario.
You should profile your app in order to find out how much time is spent on following steps:
Entities retrieved from the database (server): This can be improved using second level cache and optimized queries
Entities serialized to JSON (server): There is a overhead here because RequestFactory and AutoBean respectively rely on reflections. You can try to only transmit the Entities that you are also going to display on the client. Another optimization which greatly reduces latency is to override the isLive method of your EntitiyLocator and to return true
HTTP request from server to client to tranmit the data (wire): You can think about using gzip compression to reduce the amount of data that has to be transferred (important if you send a lof of objects over the wire).
De-serialization on the client (client): This should be quite fast. There was a benchmark that showed that AutoBean serialization was one of the fastest ways to serialize JSON. Again this will benefit from not sending the whole object graph over the wire.
One way to improve performance is to use caching. You can use HTML5 localstorage to cache data on the client. This applies specifically to data that doesn't change often.
I'm trying to display a server response time on the page similar to google's search time, something like "page loaded in about 1.3 seconds" or so.
What is the best way of achieving this? I currently have a MVC framework setup, and my initial approach was to store initial time in the controller, and pass it as the model into the view and it is up to view to calculate the time elapsed.
Somehow I feel there must be a better approach, that, for all requests, context might already have the information recorded, either the request start time, or the elapsed time.
Can someone please verify if my original thought was right? or there exists an already implemented solution?
Thanks,
Jason
If you wait all the way until your controller, you're potentially missing a lot of the "load time". You want to use a Filter to time the request from as early to as late in the process as possible. The Java EE Tutorial has more details on writing Filters. There's also another SO answer that deals with exactly this:
In spring MVC, where to start and end counter to test for speed execution time?
You could use a servlet filter to store the start time in a request attribute for each request (or at least for each request to a page), and compute the elapsed time at the end of your view execution.
If you use a template engine like Tiles or SiteMesh, this elapsed time computation would be called in a single place: the page template.
We have an application that parses tweets and we want to see the activity in real time. We have tried several solution without success. Our main problems is that the graphing solution (example:graphite), needs a continious flow of metrics. When the db aggregates the metrics it's an average operation which is done, not a a sum.
We recently saw cube from square which would fit our requirement but it's too new.
Any alternatives?
I found the solution in the last version of graphite:
http://graphite.readthedocs.org/en/latest/config-carbon.html#storage-aggregation-conf
If I understood correctly, you cannot feed graphite in realtime, for instance as soon as you discover a new tweet?
If that's the case, it looks like you can specify a unix timestamp when updating graphite metric_path value timestamp\n so you could pass in the time of discovery/publication/whatever, regardless of when you process it.
I need to write a servlet that will return to the user a csv that holds some statistics.
I know how to return just the file, but how can I do it while showing a progress bar of the file creation process?
I am having trouble understanding how can I do something ajaxy to show the progress of the file creation, while creating the file at the same time - if I create a servlet that will return the completion percentage, how can it keep the same file it is creating while returning a response every x seconds to the browser to show the progress.
There's two fundamentally different approaches. One is true asynchronous delivery using an approach such as Comet. You can see some descriptions in articles such as this. I would use this approach where the data your are delivering is naturally incremental - for example live measurements from instrumentation. Some Java App Servers have nice integration between their JMS message systems and comet to the browser.
The other approach is that you have a polling mechanism. The JavaScript in the browser makes periodic calls to the server to get status (and maybe the next chunk of data). The advantage of this approach is that you are using a very standard programming model, less new stuff to learn. For many cases, such as "are there new answers for the Stack Overflow question I'm working on?" this is quite sufficient.
Your challenge may be to determine any useful progress information. How would you know how far through the generation of the CSV file you are?
If you are firing off a long running request from a servlet it's quite likely that you will effectivley spin off a worker thread to do that work. (Maybe using JMS, maybe using asynch workers) and immediately return a response to the browser saying "Understood, I'm thinking". This ensures that you are not vulnerable to and Http response timeouts. The problem then is how to determine the current progress. Unless the "worker" doing the work has some way to communicate its partial progress you have nothing useful to say. This kind of thing tend to be very application-specific. Some tasks very naturally have progress points (consider printing we know how many pages to do and how many printed) others don't (consider determining if a number is prime - yes or no, no useful intermediate stages perhaps)