I saw on the phorum where someone asked about performance of PHPSurveyor. I am starting this thread to get any performance data anyone has. Please list your server configuration/architecture (if possible). I am really interested in hits/minute or anything of the like.

Hi!

PHPSurveyor has been used on a single machine to successfully collect 50,000 responses in 24 hours. The survey consisted of estimated 8-12 questions with accroding branching. Unfortunatley I don't have information on the machine specs.

Regards

Carsten<br><br>Post edited by: c_schmitz, at: 2006/10/12 17:18

What is the performance??? good question.. However that can be a tough one to answer. The hardware, web server, php version, etc will all factor into that. But recently I have begun to work on the performance tuning of PHPSurveyor. I can share some of my experiences.

On a small 1.8Ghz Pentium with 1GB Ram running Windows 2000, IIS, PHP 5.2.0, MySQL 5.0.24a I was able to achieve 2 transactions per second on a survey with 60 questions (about 10 per page). The response times were &lt; 5 seconds. Of course the more load I pushed the slower the response time. So the 'best' performance was 2 TPS with a &lt; 5 sec response time.

This got me looking into how to 'tune' the system. With just a few tweaks to the code and a few indexes added to the database I was able to double the performance. Now at 4 transactions per second I can see that there are still alot of un-tuned areas.

So far the focus has been on features, which are comming along very nicely, but expect to see MAJOR performance increases in the next release.

Excellent!

Greatly looking forward to your performance improvements.

Would you be so kind as to share with us your current performance modifications? What are you looking at specifically in the source PHP? What kind of tuning are you doing?

I began by profiling a survey. I started by going to the welcome page and seeing what functions were being called and how long those took. The first routine that stood out was the templatereplace() function. This routine does alot of str_replace function calls... even if what was in the str_replace did not exist in the template. So I changed those calls to do a strpos before the str_replace. This successfully improved performance by over 40% in this routine.

I then continued searching for other areas where code was being run where it really did not need to be. Another example was CreateFieldMap(). This function takes considerable amount of time and was being called multiple times on the same page request.

I also began working on the SQL statements. The buildsessionsurvey() function had a query that was run, and then for each record another query was run. On a 60 question survey this would result in 61 queries being run. I changed it to be 1 query that includes a sub-select. Performance improved by almost 20%.

There are also many issues with the indecies... they simply don't exist. Currently I am working on doing SQL Explains for the most common statements and adding those indecies (as well as improving the SQL statements).

If you are interested in trying the tuning... please download the Alpha108a2 code and compare it against the Alpha108a3 (tuned) code.

I have also been careful to include the tuning in the latest development version.

Here is the log I have been keeping concerning the changes.

Optimized Routines
===================
11/10/06 - templatereplace() - common.php - 49%
Use of strpos() and if statements to limit executing lines.

11/13/06 - createinsertquery() - save.php - 31%
Changed arraySearchByKey call to include last parameter (1), which stops looking in array after finding a match.

11/13/06 - createfieldmap() - common.php - 88%
Store fieldmap as a global array so it is only create once per page. Significant improvement in performance when
submitting and detailed email notification turned on. (16 sec vs. 2 sec)

11/13/06 - returnquestiontitlefromfieldcode() - common.php - 37%
Changed arraySearchByKey call to include last parameter (1), which stops looking in array after finding a match.

11/13/06 - getextendedanswer() - common.php - 36%
Changed arraySearchByKey call to include last parameter (1), which stops looking in array after finding a match.

11/20/06 - buildsessionsurvey() - index.php - 17%
Changed query to include sub-select which checks if conditions exist. Reduced number of individual queries that
were being run (1 for each row in original query).

11/27/06 - group.php, question,php, survey.php - Call to templatereplace() - 41%
Each template file was sent to templatereplace a line at a time, now the whole file is sent at once.

11/28/06 - buildsurveysession() - index.php - Optimized queries


Bug Fixes
==========
1. qanda.php - Fixed bug so multiple date fields on same page work correctly.
2. importsurvey.php - Allows the surveyid to stay the same during import if unused.

I noticed if you change &quot;phpalfa_survey_XXXX&quot; table type from the ISAM to InnoDB the overall performance improves significantly. The reason is that ISAM table engine during an update locks whole table, whereas InnoDB locks just one row. Now image a situation when you have 20 concurrent users filling in the same survey (updates are done after each question), then you end up in a situation that you are waiting until the data table is released. It produces quite significant delays.

I would suggest to update the table creation script in activation.php file. Instead of TYPE=ISAM should be TYPE=InnoDB.

Regards,
Zimi

Hi, thanks for the advice. I have added type table storage engine as an option in config.php. This will be in the next release.

What happens if your host has disabled Innodb support on your rented MySQL database?

Mine has.

Don't know why.

Then you run with type ISAM?

Sounds good!

Excuse the foolish post. I posted before I saw your solution as part of config.php.