I've got a Process Maker BPM 3.2
I Got Project that have 300 row in grid(With Pictures).
but form loading had delay
Does anyone have any idea who can i fix it?
Try to increase your max execution time and also your max_input_vars in the php.ini, then restart your httpd.
If you are loading a grid with 300 data with all text, there might be a tendency that it will not show all but if with picture, that will be eating up resources and loading time.
I hope this helps
Related
I'm using a GPX file which contains one point having the network source, the other points come from the gps satellite source. When playing the file and getting this 'network point', then the OnPositionChanged Listener is not triggered during 20 seconds (it should consider that the signal is still the same), I lose the next points and my app considers that the signal is lost during 20 seconds.
This behaviour comes up when playing the file without navigation, it also comes up when navigating, ...but it doesn't occur when the navigation has been launched and it is stopped. In this case, the position of the points after the network point is got normally without the 20s delay.
HERE Developer Support, could you please investigate?
Try please new 3.14 version there is fix some delays in PositioningManager. Some suggestion: if possible use please only LocationMethod.GPS during navigation and LocationMethod.GPS_NETWORK at all other cases. This suggestion works for PositionSimulator too.
I'm relatively new to JavaFX and have written a small applet which launches a number of (typically between 3 and 10) sub-processes. Each process has a dedicated tab displaying current status and a large TextArea where the process output is appended to. For simplicity all tabs are generated on startup.
javafx.application.Platform.runLater(() -> logTextArea.appendText(line)))
The applet works fine when workloads on sub-processes are low-moderate (not many logs), but starts to freeze when sub-processes are heavily used and generate a decent amount of logging output (a good few hundreds of lines per second in total).
I looked into binding the TextArea to the output, but my understanding is it effectively calls the Platform.runLater() method so there will still be hundreds of calls to JavaFX application thread per second.
Batching logging outputs isn't an ideal solution either because I'd like to keep the displayed log as real-time as possible.
The only solution which I think might solve the problem seems to be dynamic loading of individual tabs. This would definitely prevent unnecessary calls to update logging textareas that aren't currently visible, but before I go ahead to make the changes, I'd like to get some helpful advice from you here. Thanks!
Thanks for all your suggestions. Finally got around to implementing a fix today.
The issue was fixed by using a buffer coupled with a secondary check for time lapse (maximum 20 lines or 100 ms).
In addition, I also implemented rolling output to limit the total process output to 1,000 lines.
Thanks again for your invaluable contribution!
I am running a drupal commerce site, where the first request of the site is taking around 3 seconds to load. Its too high. on profiling i found out its because form_set_cache is taking around 2.5 Seconds to insert.
How to solve this, i read that it is not prescribed to move form_set_cache to memcache also since it is not static, how we can improve this.
Our flex (flare) application keeps timing out when rendering large datasets. Is there anyway to prevent this? we have tried to increase the timeout in the Application tag and the compiler settings. Not mushc success.
Any other thoughts?
regards
Sameer
You may organize the rendering work in chunks and after processing each chunk, give back control to the system. There are many possible implementations, for instance start a timer that fires event each 500 ms and process a small chunk of the dataset in the event handler.
As a bonus, processing a large dataset in chunks will enable you to provide the user the option to cancel rendering easily.
Increasing timeout is not advisable because on high network traffic it will bug users even more, the only solution is to do paging of long datasets, always load 50 to 100 items only at a time and let user navigate to pages by using pager controls.
I have been involved in building a custum QGIS application in which live data is to be shown on the viewer of the application.
The IPC being used is unix message queues.
The data is to be refreshed at a specified interval say, 3 seconds.
Now the problem that i am facing is that the processing of the data which is to be shown is taking more than 3 seconds,so what i have done is that before the app starts to process data for the next update,the refresh QTimer is stopped and after the data is processed i again restart the QTimer.The app should work in such a way that after an update/refresh(during this refresh the app goes unresponsive) the user should get ample time to continue to work on the app apart from seeing the data being updated.I am able to get acceptable pauses for the user to work-- in one scenario.
But on different OS(RHEL 5.0 to RHEL 5.2) the situation is something different.The timer goes wild and continues to fire without giving any pauses b/w the successive updates thus going into an infinite loop.Handling this update data definitely takes longer than 3 sec,but for that very reason i have stopped-restarted the timer while processing..and the same logic works in one scenario while in other it doesnt.. The other fact that i have observed is that when this quick firing of the timer happens the time taken by the refreshing function to exit is very small abt 300ms so the start-stop of the timer that i have placed at the start-and-end of this function happens in that small time..so before the actual processing of the data finishes,there are 3-4 starts of the timer in queue waiting to be executed and thus the infinite looping problem gets worse from that point for every successive update.
The important thing to note here is that for the same code in one OS the refresh time is shown to be as around 4000ms(the actual processing time taken for the same amount of data) while for the other OS its 300ms.
Maybe this has something to do with newer libs on the updated OS..but I dont know how to debug it because i am not able to get any clues why its happening as such... maybe something related to pthreads has changed b/w the OSs??
So, my query is that is there any way that will assure that some processing in my app is timerised(and which is independent of the OS) without using QTimer as i think that QTimer is not a good option to achieve what i want??
What option can be there?? pthreads or Boost threads? which one would be better if i am to use threads as an alternate??But how can i make sure atleast a 3 second gap b/w successive updates no matter how long the update processing takes?
Kindly help.
Thanks.
If I was trying to get an acceptable, longer-term solution, I would investigate updating your display in a separate thread. In that thread, you could paint the display to an image, updating as often as you desire... although you might want to throttle the thread so it doesn't take all of the processing time available. Then in the UI thread, you could read that image and draw it to screen. That could improve your responsiveness to panning, since you could be displaying different parts of the image. You could update the image every 3 seconds based on a timer (just redraw from the source), or you could have the other thread emit a signal whenever the new data is completely refreshed.