| SMPP questions |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 23, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| Alexandre New member Username: Alexd Post Number: 32 Registered: 01-2008 |
Hello! As i see in topic http://support.nowsms.com/discus/messages/1/41669.html command QUERY_SM it`s not supported in NowSMS ? this command will support in futures version ? SUBMIT_MULTI not support too? Have any list of unsupported SMPP commands ? Thanks. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1373 Registered: 08-2008 |
Hi Alexandre, QUERY_SM is under consideration for the future. Generally speaking, it is rare to find service providers that support this command. (The same applies to CANCEL_SM and REPLACE_SM.) SUBMIT_MULTI is another command that most service providers do not implement in the interest of simplifying billing operations. We might consider supporting it from a server perspective in the future ... but to be honest, there is a lack of a compelling reason to do so. -- Des NowSMS Support | |||
| Alexandre New member Username: Alexd Post Number: 34 Registered: 01-2008 |
Ok.Thanks | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 52 Registered: 06-2004 |
Implementing query_sm in the current architecture may indeed cause a drastic slowdown. The disk queue load due to write operations into the .db SQL Lite files used to track message IDs is disproportionally high. Our engineers also tested SQL Lite in some application simulating writing into tables - it's in fact this particular database which is very slow. So SQL Lite should probably be scrapped and replaced with something else before query_sm or anything else requiring to write more data into the message tracking database can be safely implemented for high-performance systems. For lower throughput though it might work fine as it is. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1431 Registered: 08-2008 |
There do seem to be a variety of tricks for optimising SQLite. I'm not a good one to explain the details, but I do know that we have gone through quite a few iterations that have resulted in improvements. We were about to investigate alternatives at one point early last year, when we stumbled across another optimisation technique. I'm not the best to explain it, but my understanding is that it had to deal with grouping multiple requests into single transactions. We were already doing that with writes, but it made a big difference in read performance, and in particular read operations slowing down writes. That said ... an SQL based database does seem like overkill for message id tracking. I can't help but wonder if an old ISAM database like Btrieve wouldn't be faster for the type of access required here. -- Des NowSMS Support | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 53 Registered: 06-2004 |
Des, I'm no expert in databases either, but our engineers had told me that writing/reading/keeping track of a table consisting of a half millon files on an NTFS volume in indexed folders was 6 times faster than trying to do the same in SQL Lite. We thought of using it, but from what I understand we won't. There are many other solutions (including simple DB-s, you're right) that don't place nearly as much stress, I was told. Kind regards, Ashot | |||
