I can’t say I have those types of benchmarks, as I’ve been working on a much smaller scale in terms of notifications. I designed the plugin to use normalized data, so I didn’t have to keep storing redundant info in the notifications table. You could easily pull it all back in one query, if you think that’s a bottleneck. What I can say is that pulling 10k records in 5 minutes with AR is totally doable, I don’t think that’s where any bottlenecks would occur. If you get some benchmarks I would love to see them.

As for storing byte arrays to AR, I’m sure it’s possible, again it’s not something I’ve had to do before with AR. If you want to fork the project on GitHub and can come up with some great performance enhancements that make sense, I’ll gladly pull that back into the project. I love when others contribute and make the project better.

I’m wondering if you have any benchmarks for large scale notifications (say 10000 devices on 5 min intervals). I’m wondering about the consequences of having a join to get to the device token when you could store the token as a 32 byte blob right on the notification. Some quick console hacking.

>> token_in = “ffffffffdbc0ce239b3d15e96efe4525941ebb8d8b65bc241eceffffffffffff” #Masked for security
=> “ffffffffdbc0ce239b3d15e96efe4525941ebb8d8b65bc241eceffffffffffff”
>> token_in_int = “0x#{token_in}”.to_i(16)
=> 111987304994859507620189752773925056744031439616140324133437380330181909811521
>> token_in_int.size
=> 32
>> token_in.size
=> 64
>> token_out = token_in_int.to_s(16)
=> “ffffffffdbc0ce239b3d15e96efe4525941ebb8d8b65bc241eceffffffffffff”
>> token_out.scan(/……../).join(” “) == token_in.scan(/……../).join(” “)
=> true

I’m not sure how easy it is (or isn’t) to attach a byte array to an AR::Base but for an app we’re building we’re dealing with a lot of notifications to a lot of devices so I’m wondering if getting the token down to a 32 byte blob would make it easy to just tack it onto the notification and save a join in the query.

Just a thought,

Corey

With the latest version, 0.3.0, I’ve wrapped the connection stuff, so you could pretty easily have it run forever with something like this:

I might put that in that version, a binary that you can run in the background that opens the connection and keeps polling for new notifications and delivers them.

I’ve actually been thinking it would be nice if there was a module for something like RabbitMQ that would just keep a persistent connection open and let the user do the notifications using normal message queues and get removes via subscriptions.

  $ ./script/console
  >> device = APN::Device.create(:token => "XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX")
  >> notification = APN::Notification.new
  >> notification.device = device
  >> notification.badge = 5
  >> notification.sound = true
  >> notification.alert = "foobar"
  >> notification.save

You can use the following Rake task to deliver your notifications:

  $ rake apn:notifications:deliver

The Rake task will find any unsent notifications in the database. If there aren’t any notifications
it will simply do nothing. If there are notifications waiting to be delivered it will open a single connection
to Apple and push all the notifications through that one connection. Apple does not like people opening/closing
connections constantly, so it’s pretty important that you are careful about batching up your notifications so
Apple doesn’t shut you down.

Does that answer your question?