I am in the process of implementing several tagging fields on my website that include an autocomplete option using the jquery UI plugin. I have everything working, and while the widget itself isn’t as robust as I would prefer (is there a way to make the first item in the list always highlighted, for instance), it is serviceable for now.
My question is around handling the server-side requests for the autocomplete data. Right now I’m using AJAX to retrieve the potential matches for the supplied input term. The table I’m hitting has around 10,000 records in it, and my thought was that rather than constantly querying that table, I could just cache a list of those records in a shared/static property on my server (I’m using ASP.NET MVC with a SQL Server backend by the way) and query that list instead. I would refresh the list every 4 hours or so, just to keep it up to date.
The idea is obviously to reduce the strain on my SQL server and maximize the performance of the autocomplete drop down. What I’m ultimately wondering is if it’s bad practice to keep a list/array of 10,000 values in memory on my server; is there a known limit/threshold here? My server has 2GB of RAM, and may need to be upgraded soon anyway.
Any suggestions would be much appreciated.
Thanks for your time!
10,000 small strings shouldn’t be too bad – I’ve done that before with no noticeable side effects.
I would recommend running your app without the items in memory, and then again with, and take a look at memory and CPU usage in Task Manager in Windows, just to get an idea of how much memory you truly are using up – that will help determine if it will cause problems down the road.
But hitting the database each time probably wouldn’t be that bad either – unless you hae a ton of traffic, the effect would likely be negligible.