I'm working on a Spring Batch Application where it is fetching data from the Oracle database. It contains around 20L of data. I implemented AsynchronousTaskExecutor with a concurrency limit of 20, the throttle limit is 10. For data source it is - spring.datasource.max-active=50
Following is the Thread Graph (JProfiler) for my application. It shows more threads in a blocked and waiting state. I want to understand why it's like this. Also, how can I improve the performance of the batch?
You have to use the views in the "Monitors & Locks" section to get more information about locking sections. If you record monitors there, the threads view (in your screen shot) will have tool tips with stack traces on waiting and blocking states.
Related
I have developed an application which works on iPhone-3GS, iPhone-4, iPhone-4S.
For start up process, it take 30 seconds on iPhone-4s , and take 50-55 seconds on iPhone-3gs. Tested on same network.(Its not an issue related to network or internet; In simulator it took only 5 second.)
In this start up process, App performs several actions like deletion of old data from Database, WebService calling and inserting response data into Database. Application calls almost 8 web service on main thread using performSelectorOnMainThread method(sequentially).
I am using SQLite and Compiled Query structure for insertion. I want to improve performance of application and want to reduce start up time taken by application.
Same back-end is used by Android team and they are also doing same thing. It takes 20 sec only on Galaxy note (Team android is using Object Relational Modal to communicate with Sqlite database ).
Is this the reason for faster performance ?
Is there anything that work same as ORM in Java for Objective-C to improve performance while dealing with Sqlite (processor specific , less time consuming)?
First thing is you should not be doing network operations (web service calls) on the main thread. That should be done on background threads. I don't know enough about using SQLite directly but with CoreData you can make "database" updates on background threads and just use the main thread for merging the two ManagedObjectContexts.
I imagine moving your WS calls to background threads (AFNetworking is a great framework btw), that you will see lots of improvement.
One example I have is a web-service based app that gets 7000 records from a SQL Server DB and creates an NSArray (data comes in as JSON) and that process takes 7-10 seconds. I further minimize the impact on the user by doing my auto-authentication process at the same time.
30 seconds is too long to have the user wait on something IMO.
14 best tips are available here Best Steps to increase performance of iOS App
In this tutorial, point 13 gives the info you required.
I need to develop the real-time application which can handle user's input (from some external control panel) as fast as possible and provide some output to LCD monitor (very fast as well).
To be more exact - I need to handle fixed-time interrupts (with period of 1ms) to recalculate internal model - with current state fetched from external control panel.
When internal model is changed i need to update a picture on LCD monitor (now I think the most proper way is to update on each interrupt). Also don't want any delays here.
What is the most suitable platform to implement it? And also which one is the most cost-effective?
I've heard about QNX, IntervalZero RTX, rtlinux but don't know the details and abilities of each one.
Thanks!
As far as the different OSs, I know QNX has very good "hard" real time and has been built & optimized from the ground up. It also now has Qt running on it (QNX 6.5) for full featured GUIness.
I have heard (2nd hand) anecdotal information that rtlinux is very close to hard realtime (guaranteed realtime), but it can sometimes be late if a driver (usually 3rd party) is not coded well. [This was from a RTOS vendor, so take it for what it is worth.]
As a design issue, I'd decouple the three separate operations into three threads with different priorities: one thread to fetch the data and set a semaphore that new data is ready, one thread to update the model and set a semaphore that the model is ready, and one thread to update the GUI. I would run the GUI thread at a much slower update rate. Most monitors are in the 60-120Hz range for updating. Why update faster than the data can be shown on the screen?
In our iPhone application we have several tabs and selecting each tab triggers network connection. In the past we were just detaching new thread for each connection. And after several very quick tab switches application was becoming unresponsive.
Now we decided to use operation queue which supposed should control number of threads and should not allow the application to become unresponsive. But now the app becomes unresponsive even with fewer quick switches (although now it recovers from unresponsiveness quicker).
I ran the app on device from xcode and paused it after several quick switches to see the number of threads. And what I have found is that there are several threads with the following stack:
0 __workq_kernreturn
2 _init_cpu_capabilities
Any idea what are these threads and how to get rid of them?
One of the big benefits of using NSOperationQueue is that you can forget about threads and let the system worry about that for you. It sounds like the root of your problem is that you've got several operations running simultaneously that are no longer needed. Rather than worrying about the specific threads, consider getting those operations to terminate so that they're no longer using up computing resources.
For what it's worth, my guess is that those threads are being managed by Grand Central Dispatch. GCD will create worker threads to process blocks (and operations), and it'll be as efficient as it can about that.
the important part of your problem does not likely lie in the internal/private implementation of worker threads. a good implementation will likely employ a thread pool because creating one thread per operation would cost a lot. operations can reuse and hold on to idle threads.
the important part (likely) lies in your use of the public apis of the implementation you have chosen.
one obvious implementation to support in this case is operation cancellation: -[NSOperation cancel]. when somebody navigates away from a view which has a pending/unfinished request, simply cancel it (unless you'll need the data for caching).
many implementations may also benefit by making requests less often. for example: if your server results only update about once per hour, then it doesn't make sense to request it 'about every minute'.
last point: a connection can use a worker thread itself - check the apis you are using to reduce this if it's a problem.
So I'm working on this application that requests and retrieves webservice content for iPhone. The problem I am running into is this: When I initially request data, it is spawned off as an independent thread so that the application does not become unresponsive due to the network being slow. What this means is that if the user navigates away from the current page before this data finishes downloading, unexpected things can happen.
I have managed to narrow down the problem cases to one relatively simple one: I have some nested tables, so if a user goes down into the "Messages" table, which can sometimes take a little while to download, then back out immediately, and select a different set of messages to view, the previous set of messages ends up loading, because it was still in the queue.
Here are things I have tried:
1) I tried cancelling the operations, but this is futile, because since I only allow one operation in the queue at the time, it triggers immediately
2) I tried validating that the recipient of the data is the same, but this doesn't work because the actual table object is the between the two selections, it just needs a different data set.
Anyone have any general programming suggestions on how to solve this tricky threading problem?
On an iPhone specific note: if I could just stop the user from being able to back out of the messages table, I wouldn't have this problem, because they would basically be locked into that view until the data has finished loading.
Thanks!
This post has some design advice relating to iOS networking and threading. The basic gist of it is "Don't use explicit threading", and I couldn't agree more. NSURLConnection has great built-in functionality for asynchronously loading data from a URL while managing all of the threading for you. They can also be cancelled easily at will.
If you were to use the NSURLConnection paradigm, you can simply cancel any pending request when you back out of the requesting view controller.
I am new to objective-c/cocoa programming. I am making an application which is to constantly sync with a server and keep its view updated.
Now in a nutshell, heres what I thought of: Initiate an NSTimer to trigger every second or two, contact the server, if there is a change, update the view. Is this a good way of doing it?
I have read elsewhere that you can have a thread running in the background which monitors the changes and updates the view. I never worked with threads before and I know they can be quite troublesome and you need a good amount of experience with memory management to get most out of them.
I have one month to get this application done. What do you guys recommend? Just use an NSTimer and do it the way I though of...or learn multithreading and get it done that way (but keep in mind my time frame).
Thanks!
I think using separate thread in this case would be too much. You need to use threads when there is some task that runs for considerable amount of time and can freeze your app for some time.
In your case do this:
Create timer and call some method (say update) every N seconds.
in update send asynchronous request to server and check for any changes.
download data using NSURLConnection delegate and parse. Note: if there is probability that you can receive a huge amount of data from server and its processing can take much time (for example parsing of 2Mb of XML data) then you do need to perform that is a separate thread.
update all listeners (appropriate view controllers for example) with processed data.
continue polling using timer.
Think about requirements. The most relevant questions, IMO, are :
does your application have to get new data while running in background?
does your application need to be responsive, that is, not sluggish when it's fetching new data?
I guess the answer to the first question is probably no. If you are updating a view depending on the data, it's only required to fetch the data when the view is visible. You cannot guarantee always fetching data in background anyway, because iOS can always just kill your application. Anyway, in your application's perspective, multithreading is not relevant to this question. Because either you are updating only in foreground or also in background, your application need no more than one thread.
Multithreading is relevant rather to the second question. If your application has to remain responsive while fetching data, then you will have to run your fetching code on a detached thread. What's more important here is, the update on the user interface (like views) must happen on the main thread again.
Learning multithreading in general is something indeed, but iOS SDK provides a lot of help. Learning how to use operation queue (I guess that's the easiest to learn, but not necessarily the easiest to use) wouldn't take many days. In a month period, you can definitely finish the job.
Again, however, think clearly why you would need multithreading.