In order to install BossTDS you will need the following hardware and software:
- VPS or dedicated server with 512M RAM or better, 1Gb is recommended (usually the TDS takes less than 150M RAM, but under extremely heavy load - hundreds and thousands requests/sec - it may take hundreds of Megabytes), with modern versions of Linux installed. The TDS will not work on shared hosting.
- Outbound connections to lic1.bosstds.com and lic2.bosstds.com, port 443 (https) should be allowed on your firewall. These are our license servers.
- ...and that's all what needed. BossTDS has it's own built-in webserver, so webservers like Apache or Nginx are not required at all, though can be used as reverse proxy. DBMS like MySQL or Postgres are not needed as well.
Consider upgrading to SSD and more powerful CPU's to speed up TDS responses. A dedicated server should be able to process 300 and more hits per second (25+ million hits a day), with no failed requests and sub-second response time.
The app doesn't eat much RAM.
The database can take several hundreds of Mb of HDD space when hammered from different IP's and/or when it has lots of data in extended reports.
Performance test
The TDS was installed on a cheap XEN VPS with 512M RAM, 1 CPU core of Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, no SSD, Centos 5.8. The price for such VPS' is less than $5/month. The VPS was located in USA.
There was 100 schemes with 10-15 weight OUT Urls each. Each OUT had one rule and one transformation. Unique hits were registered by IP address. To make it more real, the VPS vas run in mode when client IP addresses are randomized. Custom reports were turned off. We used nginx as reverse proxy. Logging was turned off for both nginx and TDS itself. Default values in boss.conf.
We used siege as the test tool. In fact, siege shows slightly lower rates than its' rivals such as wrk or ab, but we decided to use it bacause it behaves more similar to the real human traffic.
We run siege on dedicated server located in Netherlands. It was connected to switch via 100 Mbit uplink. We hit random IN Urls of all schemes. Timeout in siegerc file was set to very modest 15 seconds.
We don't guarantee such performance on real traffic, it will be almost always lower, but as a first approximation this test is well enough.
:~$ siege -c 500 -b -t 120s -f siege.conf -A "Opera/9.80 (Windows NT 6.1; U; es-ES) Presto/2.9.181 Version/12.00" ** SIEGE 2.70 ** Preparing 500 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 30022 hits Availability: 100.00 % Elapsed time: 119.81 secs Data transferred: 0.00 MB Response time: 0.98 secs Transaction rate: 250.58 trans/sec Throughput: 0.00 MB/sec Concurrency: 495.73 Successful transactions: 30022 Failed transactions: 0 Longest transaction: 1.72 Shortest transaction: 0.27
