Badai Aqrandista wrote:
...Your requests take 110 seconds each? What is your application doing?
My app is an online hotel booking system. That part is the part where
it searches availabilities through all combination of dates, number of
guests, rooms, packages, allotments, pricing structures, and more.
This doesn't sound like a "search" at all. Typically individuals know at
least SOMETHING about the
booking they want to make. How many times do you book a hotel, but don't
care whether it's in
Barbados or Brazil?
If you have a resonable set of search criteria (constraints) linked to
appropriate indexes on your data,
you should be looking at <1s responses, not hundreds of seconds.
Many online systems will either reject a search with too few critieria,
or limit the results to (say) the
first 100 hits, precisely to stop silly or malicious searches producing
a zillion results and crippling their system.
If you really are enumerating all possible combinations, not really
searching for specific solutions, this
sounds like a job for an occasionally-run batch job storing the results
into a cache table, although in
your case this sounds like a potantially huge cache
Regards: Colin.
