Geocoding in umbraco, also how well does umbraco perform with 20k pages
Scaling Peformance Question:
I am wondering how umbraco performs when there gets to be large page counts, around 20,000 or so. As I am working on a real estate site and will need to store information for about 20,000 property rentals along with manually uploaded rentals. For manually uploaded rentals it is simple enough to make a doc type that has properties such as rental price and a few image properties to store. But I am wondering if performance will crash if I import the huge list of rentals and store them in umbraco by making content pages for them.
Geocoding:
This will be my first project doing geocoding, using latitude/longitude values for a rental location so when a user enters a zip code it can find the closest rentals. Sql Server 2008 added a new geography datatype, and was recommended to use this for storing lat/long data to make fast queries for the closest properties. However there is no geography datatype for umbraco and I was wondering if anyone else had experience with setting up a search feature in umbraco that uses geocoding to find the closest results.
Thanks for any advice/help anyone might have on these topics.
I think it does pretty well up to a point - and I believe that point depends on the size of the document content as well as the number of pages.
The pages themselves are loaded into an in-memory representation of a the full xml document (at least I believe that is the case in v3 - I don't know about the v4 rc. So I think the problem may be running into swapping, memory management issues.
Having said that - I seem to remember reading that the ceiling for decent performance is generally around 200K documents. Beyond those 200K, you may be better off backending some of the data in a db and writing an XSLT extension or user control to pull it out.
I may be way off on this as I am just taking a shot in the dark - there are other much more knowledgeable forum members that will hopefully correct me.
Geocoding in umbraco, also how well does umbraco perform with 20k pages
Scaling Peformance Question:
I am wondering how umbraco performs when there gets to be large page counts, around 20,000 or so. As I am working on a real estate site and will need to store information for about 20,000 property rentals along with manually uploaded rentals. For manually uploaded rentals it is simple enough to make a doc type that has properties such as rental price and a few image properties to store. But I am wondering if performance will crash if I import the huge list of rentals and store them in umbraco by making content pages for them.
Geocoding:
This will be my first project doing geocoding, using latitude/longitude values for a rental location so when a user enters a zip code it can find the closest rentals. Sql Server 2008 added a new geography datatype, and was recommended to use this for storing lat/long data to make fast queries for the closest properties. However there is no geography datatype for umbraco and I was wondering if anyone else had experience with setting up a search feature in umbraco that uses geocoding to find the closest results.
Thanks for any advice/help anyone might have on these topics.
I think it does pretty well up to a point - and I believe that point depends on the size of the document content as well as the number of pages.
The pages themselves are loaded into an in-memory representation of a the full xml document (at least I believe that is the case in v3 - I don't know about the v4 rc. So I think the problem may be running into swapping, memory management issues.
Having said that - I seem to remember reading that the ceiling for decent performance is generally around 200K documents. Beyond those 200K, you may be better off backending some of the data in a db and writing an XSLT extension or user control to pull it out.
I may be way off on this as I am just taking a shot in the dark - there are other much more knowledgeable forum members that will hopefully correct me.
Best regards,
Hal
Thanks for the info.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.