General slowness in basic operations
Hi ME Team,
Id like to report you an issue of general slowness in SDP. Sometimes it gets son slow that its necessary to reboot it.
From the tab support, i identified that regarding the "count number", it takes almos 1,5 minute to index the table "NotificationToDesc", which is a lot.
Table Name |
Count |
Time Taken (ms) |
NotificationToDesc |
310330 |
89500 |
Notification_Recipients |
1330703 |
8016 |
Arc_Notify_Recipients |
1739308 |
7282 |
Both SDP server and MSSQL server have 4Gbs RAM and are VM servers of 4 core duo 1,8ghz.
I have come across with this article:
Technician Logins |
No. of Nodes |
Processor Type |
Processor Speed |
RAM |
Free Hard Disk |
5-20 |
50-200 |
Intel Core Duo |
1.7 GHz |
1GB |
20GB |
20-50 |
200-500 |
3.4 GHz |
2GB |
40GB |
50-100 |
500-2000 |
2*3.4 GHz |
4GB |
40GB |
100-200 |
1000-5000 |
4*3.4 GHz |
4GB |
80GB |
but in different scenaries we have no idea, if for example for more than 200 technicians or around with, around 100000 active tickets in only one year, each with minimum 10 notifications (slas, assignement notifications, etc) what will be the desired structure.
The problem is that, SDP is each day impossible to work it, and the IT responsables are considering other softwares to replace it with.
How can you help me in this matter?
Whats the safest scenario to work with SDP MSP, regarding notifications volume, number of technicians, number of nodes, number of costumer accounts and requesters, etc?
My company has SDP MSP working for 3 different countries, with more than 1500 costumer accounts and almost 4 requesters per account.
Thank you very much.
MIGUEL LAMPREIA
New to ADSelfService Plus?