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, you cannot just use the default OSC. Use a ERXTaskObjectStoreCoordinatorPool just for tasks, even if it is just a pool of one. Also, if I get a few minutes later or at the weekend, I can eyeball your setup for possible low-hanging fruit if you send the following: A) Send your /etc/my.cnf file to the list, and tell me how much total max memory you want mysql to have - I will take a quick look at it to see if it looks OK. B) send the output of the following SQL statement in a text file: select TABLE_SCHEMA, TABLE_NAME, TABLE_ROWS, (DATA_LENGTH + INDEX_LENGTH)/1024/1024 as SIZE_IN_MB, DATA_LENGTH/1024/1024 as DATA_SIZE_IN_MB, INDEX_LENGTH/1024/1024 as INDEX_SIZE_IN_MB from information_schema.TABLES order by SIZE_IN_MB desc; C) send the output of the following SQL statement in a text file: SHOW VARIABLES; D) Send the output (allschemas.sql) of the following CLI statement: mysqldump --all-databases --opt --no-data > allschemas.sql On Jul 29, 2011, at 10:56 AM, Andrew Kinnie wrote: > 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 : >> >>> 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? 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 globalIDs >>>> to prevent problems. Also, make sure you don't lock the OSC for the app >>>> during your work or your app will hang while other threads' ECs wait to >>>> get it. If this gets bad enough, use a separate OSC stack and dispose of >>>> it when your done. >>>> >>>> John >>>> >>>> Sent from my iPhone >>>> >>>> On Jul 29, 2011, at 9:28 AM, Andrew Kinnie <[email protected]> wrote: >>>> >>>>> 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 (i.e. an >>>>> iOS device which has our iOS app), Notification and has a lookup table >>>>> for NotificationType (5 rows). Notification is a message, and there is a >>>>> many to many with ApplicationDevice along with a corresponding >>>>> device_notification table, as well as ApplicationDeviceNotificationType >>>>> to allow particular devices to have particular types of notifications >>>>> turned on or off. >>>>> >>>>> Our app in connected to by our editorial staff via a Cold Fusion app to >>>>> send out breaking news alerts as push notifications. I then get (via a >>>>> fetch) all the devices which have that particular notification type >>>>> (basically 90% of our 20,000+ "installed" applicationDevices), then I >>>>> pass that array into a method which makes the connection to Apple and >>>>> iterates through the array sending one notification to each device in >>>>> turn, then closes the connection. >>>>> >>>>> It takes approximately 1 minute to send an alert to all 20,000 devices. >>>>> >>>>> While this happens, some of these devices are getting the push from Apple >>>>> (which is crazy fast about it), and some of them are running the app and >>>>> the iOS app itself is querying the server for details about the >>>>> notification and loading it in. However, if this happens while the push >>>>> is still in the process of sending (i.e. within the 1 minute time frame), >>>>> the iOS app may be forced to wait for the send process to finish (as many >>>>> as 60 seconds presumably. It doesn't happen all that often, because our >>>>> app doesn't buzz or makes a sound when it receives a notification, but it >>>>> is not ideal. We anticipate using this same app and server for the >>>>> Android version, and for the upcoming iPhone update, so the number of >>>>> installed devices could increase pretty dramatically. Currently it is >>>>> iPad only. >>>>> >>>>> So, we're trying to figure out what to do about it. Currently the app is >>>>> deployed on a CentOS server (single core processor) which also houses the >>>>> db, but nothing else. It has 16 GB of RAM. >>>>> >>>>> We were considering: >>>>> >>>>> 1. Trying to increase the threads the app can create, but I'm not sure >>>>> that would fix it as much as mask it >>>>> 2. Trying to run an additional copy of the app to send while the other >>>>> one handles the incoming client requests, but I am not sure how to >>>>> accomplish this other than copying the whole project, renaming it, then >>>>> deploying that. I am also not sure this would fix anything if in fact >>>>> the issue were locking in the database or jdbc or something of that >>>>> nature. >>>>> 3. Seeing if there was something easier, more efficient and less kludgy >>>>> feeling than either of those. (assuming either of those would work >>>>> anyway, we have some difficulty testing it without sending out 20,000 >>>>> push notifications) >>>>> >>>>> Anyone have any insight? >>>>> >>>>> Andrew >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/the_larsons%40mac.com >>>>> >>>>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/alexis.tual%40gmail.com >>> >>> This email sent to [email protected] >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
