I thought I should update the list, following our testing a clone of the
database, with a timer to delay between the devices without actually sending.
It appears the combination of turning concurrency on per Pascal (seems to me
that should be the default) and then using Kieran's suggestions for
IMMEDIATE BAND-AID 60 second FIX
1. Go to Monitor, create a new 'Application' named Admin and select the
current application executable path, launch an instance and use that Admin
instance for sending notifications. (You don't need to copy the app, rename and
redeploy
Thanks. We already implemented several of these (based on Pascal's suggestion
about concurrency being turned on, I assumed that was the default but was
apparently wrong). Concurrency and 4 instances have dramatically reduced the
occurrences of long wait times. Down to something like 4 out of
Greetings
I have a deployed app which serves as a push notification server for our iOS
app. It uses a recent ERRest (post WOWODC) to provide access to the data which
is located on a MySQL database (using innoDB). The model has entities for
PushApplication (the iOS app), ApplicationDevice
First question: does concurrent request handling
(application.setAllowsConcurrentRequestHandling(true)) is enabled? If not, just
enabled that and you will probably fix most of the performance issues...
After that, you need to get metrics to find out where the bottleneck is...
Bandwith? CPU?
rather than increasing worker threads, why not just spawn a new Java thread for
sending the notifications? That thread can run in the background while you're
doing EO stuff and free your app up to do the servicing of requests.
If you go down this path, I always pass EOs to other threads as
Is that something I would put in the Application constructor? Should that be
in a property somewhere?
As for the rest, it appears the issue is in the WO app instance. Requests that
go to the second instance seem to have normal response times. My IT guy says
the entire db is less than 60 MB,
Thanks. I may give that a try. That was one of the other options I thought
of, but was hoping to avoid a significant re-write.
On Jul 29, 2011, at 10:44 AM, John Kim Larson wrote:
rather than increasing worker threads, why not just spawn a new Java thread
for sending the notifications?
Le 2011-07-29 à 10:50, Andrew Kinnie a écrit :
Is that something I would put in the Application constructor? Should that be
in a property somewhere?
public Application() {
ERXApplication.log.info(Welcome to + name() + !);
/* ** put your initialization code in here ** */
An example of all that John said is available there thanks to Kieran :
https://github.com/projectwonder/wonder/tree/master/Examples/Misc/BackgroundTasks
Alex
Le 29 juil. 2011 à 16:52, Andrew Kinnie a écrit :
Thanks. I may give that a try. That was one of the other options I thought
of,
well that's a pretty solid point. I had thought it was already huge but I
suppose I can exert some pressure now.
On Jul 29, 2011, at 10:54 AM, Pascal Robert wrote:
Le 2011-07-29 à 10:50, Andrew Kinnie a écrit :
Is that something I would put in the Application constructor? Should that
That will help, thanks!
On Jul 29, 2011, at 10:55 AM, Alexis Tual wrote:
An example of all that John said is available there thanks to Kieran :
https://github.com/projectwonder/wonder/tree/master/Examples/Misc/BackgroundTasks
Alex
Le 29 juil. 2011 à 16:52, Andrew Kinnie a écrit :
Le 2011-07-29 à 10:55, Alexis Tual a écrit :
An example of all that John said is available there thanks to Kieran :
https://github.com/projectwonder/wonder/tree/master/Examples/Misc/BackgroundTasks
And hopefully, I will add a REST example in there before the end of the month.
Alex
Le
Andrew,
Hi Andrew,
Just to endorse what some have said, after reading this thread:
1) concurrency must be ON
2) For your 1 minute task do it in a background thread and use a different OSC.
Remember EOF is a single-threaded, single-db-connection stack. If you want high
concurrency performance,
OK, thanks.
I have implemented a simple task version of my old utilities class to run the
sends, but I did not know that about EOF being single threaded or the single db
connection. I will look at the ERXTaskObjectStoreCoordinatorPool.
BIG help.
I attached the query results and the show
OK, I have done a little searching and poking around in source, and am not
finding how one should do the multiple OSCs solution.
I see there is a property to set to determine the size of the pool, and I see
how to get an OSC from a pool, but I don't see anything else about what I need
to do to
Check out wonder source and run the BackgroundTasks example and look a the
examples themselves. Also watch the video for that from this year's WOWODC.
Pascal sent it out to attendees recently.
On Jul 29, 2011, at 4:53 PM, Andrew Kinnie wrote:
OK, I have done a little searching and poking
OK, thanks. I thought I looked through the example, presumably I missed
something. In any event, yes, watching the session again makes lots of sense.
Maybe it will give me something to do while I avoid 100 degree heat this
weekend.
Andrew
On Jul 29, 2011, at 4:56 PM, Kieran Kelleher wrote:
18 matches
Mail list logo
