7 Replies

It's just more of a recommended limit but it's by no means hardcoded in the program to only only accept 250. Performance played a factor in determining the number. It's like using a flat file and DOS batch commands to run your local grocery store computer systems. It may work but will be painfully slow but may be an acceptable solution for the corner variety store.

Spiceworks made this product to support the SMB market. If you're looking at more than several hundred devices, you may need to seriously reconsider if Spiceworks is the right management tool for you (although I'm not trying to dissuade you from using the product).

Do you say that spiceworks will stay this way? I still had hope that another DB technology like MS or MYSQL would push the performance to an acceptable level. We have around 500-600 devices in our DB and I would say we are a SMB company but having a lot servers and a lot of our users having two devices. (NB plus PC)

There is still the feature request concerning another DB. Is there something planned with the next release and will this push performance to a niveau where it can store more then 250 devices without slowing down so much?

I personally would like to see Spiceworks have alternate options but I think the only way they can achieve this is to run on a more tightly coded language other than Ruby. Heck, even Java, I find, is too bloated a language. They seem to carry a lot of baggage. But then again, I'm not a programmer. But with the Spiceworks model, they do control a lot of the "under-the-hood" features, especially since they update their code remotely. With that, it would be most difficult to manage and update.

Using a different database wouldn't speed up the program. It's the WMI gathering that causes the issue. Because of the way Spiceworks situates itself in the industry by not requiring any client software, it must discover and connect to each system as it scans entire IP ranges. And it must gather all its information again to check for changes. It's not like a client that could do all that and send the changes to the main server which would keep things VERY fast. Spiceworks' convenience comes at a price - performance. If you want speed, that comes at a price too - cash for an alternate system using a client.

And there really is no industry standard definition for SMB. It's not like they can determine it in terms of employees, computers, profits, etc. There's nothing to stop and enterprise from using the solution. Heck, even the multi-user capability came from the larger SMBs that had more than one technical user who needed access to Spiceworks. If there's enough interest, you may see a slight paradigm shift but I wouldn't expect to see that for another two years or so.

With the direction of Spiceworks in terms of feature requests, the guys with orange avatars would have to respond. As a product advisor, I'm a glorified techie with a passion for Spiceworks but am not paid by nor work for them. I do get very limited updates on features appearing in future releases and so far that one didn't make it.

Thanks a lot for your detailed answer. I get your points and it seems to me that you are right. So.. I am an optimist and still there is enough pressure on this product cause of it approaching so many different technical needs in one tool. Maybe if it gets enough interest and reaches enough people the need for a stronger solution rises.
Anyway. If I read through all the threads and posts I already get the impression that more than 3 quarter of all users in the forum would appreciate a performance-enhanced version of SW.

I know Spiceworks (Francis I think it was) was looking into making some slight detection routine changes to speed up the scans. Those may make it for the release by the end of next month but I have not been given a list of improvements to expect in the next release. Unfortunately with the way WMI is, it sits on top of several other protocols (RPC, DCOM). The more protocols in the mix, the more memory intensive any scan using WMI will be. It's a good in-roads into Windows machines and it spans all common 32-bit versions (natively and by installation depending on the version) which is why many management systems use it. Unfortunately it is slow.

Feature requests for clients have been asked. I don't foresee that being implemented for a while but I do agree that there is a need for something quicker and that requires less configuration.