| Queuing problems/ideas |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through December 01, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Mindaugas Riauba Unregistered guest |
After two marketing campaigns (~10k MMSes each) I think that NowSMS queuing is a bit weak. As far as I understand now one thread puts MMS into queue and then other thread more or less randonly takes MMS from queue and tries to send it. This leads us into the following problem - after some time queue is getting bigger because quite a lot of MMSes cannot be delivered at once. Then new MMSes are put in the big queue and waits till they will be tried to deliver. MMSes are submitted via SMTP but at a rate lower than our licensed rate. So I have few ideas how to improve queuing. 1. Put new messages into "new" queue. Then try to deliver them at a higher priority. If first attempt is unsuccessful move message into "normal" queue which is processed like now. 2. Make some "high priority" queue for important messages (OMA settings e.g.) and some rules or methods how to put messages into it. 3. Make "bulk" queue for such mass messaging. And then divide licensed rate 50:50 between "normal" and "bulk" queues. That is if our licensed rate is 60 messages per minute and both "normal" and "bulk" queues are full send 30 normal and 30 bulk messages per minute. Maybe good option can be "work hours" for "bulk" queue. That is that messages will not be sent at night. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3269 Registered: 10-2002 |
I ususally recommend setting up a separate system for bulk MMS sending. That way the bulk queue doesn't get in the way of normal traffic for user-to-user MMS and OTA configuration. That said, we are current looking at ways to implement multiple queues, and to assign different priorities to the different queues. Our current thinking is somewhat similar to your idea #3. But instead there would be multiple queues, one for each "SMS Users" and "MMSC VASP" account. Each of these accounts would have a numerical value priority associated with it, and that priority would affect how its messages are sent out. The idea is to then balance the traffic relative to the priorities. For example, let's say the "SMS Users" account used for OTA has priority level 50, the bulk MMSC VASP account has a priority level of 10, and the user to user MMSC has a priority level of 40. If all of those queues were backed up, in the next 100 messages sent (subject to license throttles), 50 would be OTA, 10 would be the bulk MMSC VASP, and 40 would be user-to-user MMS. If the OTA and user-to-user MMS queues were not backed up, as new messages are added to that queue, they would have higher priority than the bulk MMSC VASP and would typically get sent out very quickly while the VASP queue is worked separately. That's just a simple example, in a typical environment, you would have more queues, and possibly multiple bulk campaigns going on at the same time. We're still working out the logistics of this, so it's likely a couple of months out yet. We'd certainly welcome more input on this. | |||
| Mindaugas Riauba Unregistered guest |
So we seem to have similar ideas  . Just separate queues for each VASP account may be not enough. For example we have single VASP account and all MM4/MM7 outgoing and incoming messages are routed through Postfix SMTP server. And one more notice - do you plan to hash MMSC users into more directories? Currently single MMSCUSERS directory with tens of thousands files is hard to manage and I think may slow things down. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3305 Registered: 10-2002 |
Yuck. I'd definitely encourage you to look into ways that you could configure multiple VASP accounts instead of a single account. With that type of setup, the only thing that really could be done is to separate out bulk priority messages. (Which is something that we are looking at doing ... however, this requires that the submitting side adheres to a bulk submission policy ... whereas the multiple queue approach described above can better adjust itself dynamically to current conditions.) Hashing that directory is a good point. Currently we only use that directory for managing statistic information and MMSC user quotas. However, an extremely large number of files in a single directory does present potential performance problems. I've made a note of this issue as one that we need to address, probably at around the same time that we readjust the queueing mechanism. | |||
