Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: OT: Scalable web application architecture

by Ryszard (Priest)
on Dec 07, 2005 at 11:54 UTC ( [id://514813]=note: print w/replies, xml ) Need Help??


in reply to OT: Scalable web application architecture

You've not mentioned on what hardware you're running this system on either.

If you've got a "large" database on a "small" machine, you'll be wasting your time attempting to optomise it. Get another machine!

memory, is an order of magnitude faster than IO, so, if you can, cache your db in memory! Also indexes, create indexes for the most commonly hit items, or at least revise your indexing strategy

You say its an online reservation system, then say you cache your results. This prima facie sounds like a bad design IMO. I've got in my mind something like a hotel reservation system, which is an OLTP system. It doesnt make sense to me to cache results, as they have the chance of being immediately out of date.

That being said, if you're caching your result set, it is probably ok :-).

Have you thought of prerunning the most expensive queries periodically (and even perhaps on an offline copy) and using Cache::Cache ? its super quick and adds only a couple of lines to each module.

Its a work around for sure to a performance based problem, but its something you could get a good lot of milage from.

Replies are listed 'Best First'.
Re^2: OT: Scalable web application architecture
by badaiaqrandista (Pilgrim) on Dec 07, 2005 at 12:51 UTC

    It is running on a P3 machine with 1G RAM (I forgot the speed). The box is dedicated for MySQL server, so it's got all the resources to itself.

    Yes it is a hotel reservation system. It has a fairly complex rules to search for availability. Rooms have maximum capacity. Packages have minimum and maximum number of guests, there are also different special packages for valued guests, travel agents, online marketing referrals. Prices can have seasons and each season can have different prices for different room-package combination. There are more rules.

    Searching for availability must consider those variables. The results from these computation for a given date is stored in a so-called 'search cache', so the next search on the date don't need to do the computation again. The problem with this is that all search use this table, so it is havily read, but if its data isn't valid, it is updated/inserted, which makes it havily written as well.

    I am looking for suggestion to improve performance for a real time system like this and to hear what other monks think about my approach on the problem. Thanks a lot for reply.


    badaiaqrandista

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://514813]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2024-03-28 23:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found