a fellow mvp, brian rogers, started drilling me about sms reporting the other day (probably because all the smart people are hanging out in san diego drinking margaritas and eating fish tacos in Old Town pretending like they're at a conference). the questions started around how to best setup sms reporting for load. hashing back and forth the basics, it was assumed that sms reporting probably taxed sql server the most ... since the only bottleneck was page faults.
brian alluded to a possible problem where the sms reporting function executes one request at a time. we started looking into this and discovered this to be the case. reviewing logs, he discovered that this was indeed the case. i did the same test myself and found that to be happening. the reporting point is, in fact, single-threaded. even though the database can handle multiple queries, the reporting point only sends one at a time. if the browser is closed after a query is sent, the query request does not end. in fact, it'll keep running on the server until it has completed or timed out. this means anyone running a massive report can stall anyone else's request.
i can only speculate that the single-threaded operation is to ensure that reporting doesn't overwhelm the sms server/database from fulfilling other functions. the problem here is, what if you have a design where reporting is handled from a database with no clients? that implies that regardless of it functioning solely for the purpose of reporting, it is still single-threaded.
it seems the only solution is to add additional reporting points that users can connect to and request reports with.
UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress. if you are using the v2 toolkit, PLEASE read this blog post before proceeding. here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can
Comments
Post a Comment