http://qs321.pair.com?node_id=514748

badaiaqrandista has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

I am a Perl programmer maintaining a webapp product of a startup company. It is an online reservation system. Currently, our product is going through the transition phase. It started from a bunch of cgi scripts and ad-hoc database schema. Now it is projected to be a mature web application with a well designed module library and demanding requirements, like robustness, reliability, and availability.

As the programmer responsible for its architectural design, I have rewritten as much as 90% of its code, resulting in around 300 classes. The code is now fairly maintainable.

Now I have problem with scale. I didn't think about the scale when designing and then my class structure made the search functionality runs really slow. Search functionality is the heart of my application, so it must be quick. To fix this I made a lookup table to cache the intermediate results of the search, so that only the first search runs slow and the following ones run faster. And I also break some of the abstractions to get better performance from the class library. This solution worked.

However, nothing ever runs according to plan. Apparently, when it gets too many requests, some SELECT queries starts timing out. And also, UPDATE and INSERT queries lock the SELECT queries out of the cache table, making the search performance much worse.

I'd like to hear from other monks on how a medium or big web app application is (or should be) designed and deployed. I'd also like to hear if anyone can help me solve this scalability/speed problem. I use MySQL 4.1 on debian sarge.

English is not my native language, so aplogise for any grammatical errors. If you need me to explain more about my problem, just let me know. Thanks.

badaiaqrandista

Update: Thanks for all the replies guys. I guess I definitely have to modify the database structure to be more suitable for data retrieval and speed. I also have to split the 'search cache' table to hold different types of data, static and dynamic. Furthermore, I'd have to optimize as much as possible.