| How to send large amount of MMS |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through July 14, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
I have installed and testing the Now.Sms, In our real world, we will need to send up to 40000 Multimedia messages (broadcast). So, how many time will be necessary to send all of them? How many MM per second can the MMSC send? (I know that dependes too much of the machine where is running, but in a normal machine 1 processor 2.8 Ghz, 1024 GB of RAM) The MMSC supports multiples processors? Support means if the Now SMS will use both not just one of them Thanks a lot AA | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2584 Registered: 10-2002 |
AA, It really depends on how you are sending the messages, and by that I mean the connection to the SMSC or MMSC. That is where the bottleneck typically occurs. It sounds like you're using NowSMS as an MMSC, in which case it is going to send out the notifications over SMS. That's good, because there are less variables to consider there when it comes to bottlenecks. So I figure what better to answer your question than for me to try a quick test. I usually tell people that 1000 recipients per submission is a good maximum, but for this case, I figured I would try 40,000 recipients in one submission. So, I've generated an MM7 document with 40,000 recipients in it. Now the problem is figuring out a quick way to post it. I often use cut & paste for this purpose ... but this MM7 request is over 1MB in size, so I'll have to write a quick and dirty program to submit it. The first thing that I found was that you want to make sure the recipients are BCC instead of TO. Otherwise the MMSC creates a very large MMS message that includes a complete list of recipients within the MMS message. (We will correct this in the next release, so that such large TO or CC recipient lists are not generated within the MMS message itself as no MMS client would be able to receive such a large message.) It took the MMSC, running on a single processor 2.4Ghz Pentium 4 with 512MB RAM, just under 5 minutes to process the request, and queue the MMS notifications for delivery over SMS. That seemed slow to me. Almost 5 minutes elapsed before the MM7 response was sent back, and most clients would time out with a wait that long. So I sat down with another engineer to analyse the processing flow and look for inefficiencies. We found a number of minor inefficiencies, and can find ways to shave a minute off of that time. But we'd have to do a far more detailed analysis to shave more time off. So for 40,000 messages, it takes about 5 minutes to generate the notifications, which is 80,000 SMS messages in a typical configuration. (If you can use a very short host name for your system, it is possible to get an MMS notification to fit into a single SMS message, which is worth pursuing for this effort. See http://support.nowsms.com/discus/messages/1/417.html for details.) Then you are talking about the amount of time that it takes to transmit 80,000 SMS messages (or 40,000 SMS messages). That speed is going to depend on the speed of your SMSC connection(s), and your NowSMS license. NowSMS is licensed based upon the speed at which it routes the SMS messages outbound. It would take almost a day to route 80,000 messages at 1 per second. Take that to 10 messages per second, and it's just over 2 hours. Use a short MMS host name to allow the notifications to fit into a single message, and at 10 messages per second, it's just over 1 hour. You could also look at configurations faster than 10 messages per second, if your SMSC connection will support that (SMPP based, right?). I'm focused on the speed of the SMS transmission, because that is really the bottleneck here. There is still the matter of the MMS clients connecting back to the MMSC to retrieve the message content. But there is not as much overhead in that process, so it is not a concern. Would multiple CPU's help? It depends. Faster CPU would definitely help ... particularly on that 5 minute processing time for the MMSC to accept the MM7 message with 40,000 recipients. Multiple CPU would only help if there are multiple CPU intensive activities occurring at the same time. For example, during that 5 minute interval, the SMS side of NowSMS is going to start sending out those notifications. An extra CPU could help it there. But other than that, I don't think it would make much difference, unless you configure more than 1 SMSC connection, in which case you could see some benefit. The MMSC will be doing more than one thing at a time when the clients connect back in to retrieve the MMS content. And multiple CPUs would be used there, but this is not a CPU intensive process, so that's why I discount the multiple CPU benefit there. I hope that helps in your consideration. I'm still concerned about that 5 minute window, so we're going to do some more investigation there. But in the big picture, I guess 5 minutes isn't really that significant for this type of bulk process. -bn | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2589 Registered: 10-2002 |
We've been running some additional tests on this and noticed something very interesting. If we follow the advice in the thread that I referenced above, so that we cut down the size of the MMS notifications, so that there is 1 SMS required for each MMS notification, then the 5 minute window that I was concerned about drops to just over 2 minutes. We are running more tests to better understand the issues, but I thought this would be of interest. | |||
| Anonymous |
Thanks a lot Bryce. I see that the MMSC sent SMS messages up to 140 characters, why not 160? that is the really limit? Can I change that value? I saw too that when I send MMS over the MM7 interface the MMSC generate a very big transactionID.. 20040513/11/F36DD19C.MMS and put this transaction id in the SMS which increase too much the number of bytes. So, I think that is not possible to reduce the number of bytes to 160 bytes. Or is possible? Another question, I don't know how the MMSC is implements, but maybe could improve the performance if... When a MMS is sent to a large amount of recipients, the MMSC could create just one MMS message and N (one per each recipient) flags that indicates if the recipient read or not the MMS. So, one Multimedia Message could be enough. Anywhay... Thanks a lot Bryce! AA | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2598 Registered: 10-2002 |
140 bytes is the limit in GSM environments. The limit is 160 characters for text messages, because a 7-bit character set is used, and 160 7-bit characters can be packed into 140 8-bit bytes. (140*8/7 = 160)
That is the MMS message file. That file is not sent over SMS. Only a reference to the file goes out over SMS. This file will contain all of the components of your MMS message, so it could be somewhat large. Do make sure that if you are sending to a large list of recipients, your MM7 submission specifies the recipients in "BCC" headers, and not "TO" headers. (That is the problem that I noticed when I first tried this above. The ".mms" message gets very large because of the "TO" headers, and it becomes so large that most MMS clients could not process it.)
That is basically what it does. But it also has to generate SMS messages to be sent out as part of the process. The MMS reception process begins with an MMS notification trigger, which is sent via WAP push over SMS. -bn | |||
| Anonymous |
cool. Thanks. I'll try to put the notification in one SMS, If I can't I'll back again  AA | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2614 Registered: 10-2002 |
One more note on the size of the notification issue. The sender address for the MMS gets put into the MMS notification. (There is a configuration setting to not include it, but this is not recommended as some phones default to rejecting notifications without a sender address.) Therefore, keep your sender address short. An e-mail address is often best, as phone numbers get /TYPE=PLMN appended to them which adds 10 characters. -bn | |||
