Thanks for your reply. I have just sent a e-mail to "help mailing list", my e-mail it is enclosed below. If I get a solution I will add the information here then it may help other users.
We were wondering if you can help us, mailing list is our last chance after use Mantis forum. All the information is at this forum post:http://www.mantisbt.org/forums/viewtopic.php?f=2&t=22070
I will try to summarize what our problem is.
We are using Mantis for bug tracking, its running without problem, but we are considering using this application & server during 2 weeks for another special process. That means that we are going to increase significantly the number of Mantis users during these 3 weeks, our estimations are the following: 5000 users; almost 500 concurrent users.
Each user must submit 2 issues, as we have almost 5000 users, so ~5000*2 = ~10000 issues in 2 weeks, this is what we expect. Unfortunately there is not a lineal distribution, most of our users used to wait till the end of 2 weeks period to submit their two issues. So during the last days of the period, we expect peaks of more than 400 concurrent users submitting issues**. Really, these peaks are our main concern; we want to know if our current server will be able to support this amount of concurrent users. Right now our server is working well, but without dealing with huge concurrent users peaks, usually there are no more than 10 concurrent users.
We haven’t found any documentation about server escalation recommendations, we have gotten a great support at Mantis forum, but unfortunately there is no answer for our question.
Our server characteristics are the following.
HW: Virtual Server with 4 cores, 8GB RAM, 50GB HD.
SO: Windows 2008 R2
Web Server: IIS 7.7
BBDD: MySQL 5.5 (using the same server)
Mantis Version: 1.1.2
Please, we were wondering if you could give us some help with the following questions.
1) Could support our server that amount of users? Shall we migrate Mantis to a new server?
2) What should be the requirements of the new server?
It’s a two weeks process, and during these two weeks
**Note: Last years, to mitigate these issues (with other tools) we defined several process end dates (between 5 to 7) in order to reduce the number of users per end date. We reached 400 concurrent users with this approach, and that means that the process needs three weeks instead of two weeks, we cannot delay it more time.