I have a website that is built on drupal 7 running on nginx with php5-fpm and memcached, apc etc (using perusio's drupal with nginx config). Running a blitz I get


Doesn't seem too bad considering that I only have about 3500 visitors/month. So what's the problem? A color genetics calculator that is a total resource hog. When someone is using the app page loads go from under 2s to over 5s and that is with only a couple of people online. The app is currently running outside of the drupal base. This is my biggest website and I don't have much experience. Mostly I just read a bunch of tutorials and plug and play until I get something that works well. (I also wrote the app so I won't vouch for the efficiency of the coding)

I would like some advice on caching the results of the app. Currently it is recalculating each time it's ran which is really unnecessary considering the results of any combination don't change unless I update the app. I think nginx can store the page results indefinitely? How would I set it for the app only without affecting the drupal part of the site? If I wrote a module and added this into drupal how would it affect things?

If you need more information let me know.

Thanks for your time

The app can be found at http://colorgenetics.info/equine/foal-c ... calculator

_________________
Color Genetics

You seem to have a lot of options when you include dilutions or white patterns. Can't you store the results of your calculations in a database using the selection criteria as a key?
- visitor clicks 'Submit'.
- your code assembles the unique query index out of the values from your select elements (eg, EeAAtggprlprl-eeAtAtggCcr).
- you check your search_results_table for rows with that value (e.g.,where search_index = 'EeAAtggprlprl-eeAtAtggCcr').
- if you find any results you display them.
- if you get 0 results you calculate the results, store them in your search_results_table and then display them.
- when you change your algorithms you just delete all the rows in your search_results and let the queries build up the new results for you.

You could also do the same thing by storing the formatted HTML results (just the results HTML, not the entire page) in files that use the query index as the file name.
- visitor clicks 'Submit'.
- your code assembles the unique query index out of the values from your select elements (eg, EeAAtggprlprl-eeAtAtggCcr).
- you check if a file exists in your results directory with that name (using a .html extension is probably a good idea).
- if the file exists display the results.
- if the file doesn't exist you calculate your results, write the results to a file with the correct name and display them.
- when you change your algorithms you just delete all the files in your results directory and let the queries build up the new results for you.

I feel like even more of a newbie now That is really obvious and I completely missed it.

Thank you!

I'm actually doing a bit of that already as I have the generated images saved after the app compiles them so that they are not generated after the first time just called. The difference is that I them named after the results not the inputs. So the results still had to be generated each time.

_________________
Color Genetics

We all learn something from every project, or every upgrade to an existing project.

Trying to optimize your entire application can be tough to do. Take a good look your process flow, break it into components and see how you can optimize things one component at a time starting with the biggest bottleneck.

Edit: Boy, I missed something obvious here ...

The images you're using are tied to the results, which is the correct way of doing it since the color results are predictable and are a significantly smaller number of possibilities as compared to the input combinations. You should continue to handle this the way that you are.

BTW, your site says it could take up to two minutes to calculate the results. That's a long time for a calculation. You may want to look at improving the efficiency of the algorithm you're using.