Hey Sean, 2009/4/12 DeNigris Sean <[email protected]>: > My server has almost 20 different options for FastCGI apps. What > would be the best settings for Wt? Are there any settings that are > always (or almost always) best/incompatible?
Unfortunately, much will depend on the server software you use, and documentation is quite sparse about many of these options. A google learned me that you are using LiteSpeed, right ? As we have no experience ourselves with this server, I am only speculating on the effect of many of these parameters based on the LiteSpeed documentation, so you will want to experiment a bit... > E.g. > Max Connections You should set this high enough as it is the number of concurrent requests that can be handled, and with the same value as Instances. > Initial Request Timeout (secs) > Retry Timeout (secs) These 2 timeouts are used to detect problems with your application -- this should depend on the complexity of your application. > Persistent Connection > Connection Keepalive Timeout These options do not apply: Wt itself will close the connection to the server after each request. I actually thought this was the only correct way. > Response Buffering You probably want to turn this on in order to free the Wt application as quickly as possible to handle another request/session, while the response is transmitted to a possibly slow host (only if you are deploying on the Internet). > Instances This should have the same value as Max Connections. If you are looking for high performance deployment, you should not discount the wthttpd connector all too quickly. Unlike the FastCGI deployment many of these performance tuning options (like max connections) do not apply because the wthttpd is completely async I/O: it can have as many open connections as needed with virtually no performance/memory cost, and it will handle as many requests concurrently as you give it threads. You can also start it behind a (load-balancing) reverse proxy if you want. It also makes well use of all the performance tuning options of HTTP 1.1 (persistent connections, gzip compression, etc...). And it will buffer the incoming requests and outgoing responses while doing the async I/O processing. Our experience is that when using apache as a reverse proxy in conjunction with wthttpd applications, the apache server is the bottle-neck with its archaic synchronous I/O architecture, not the Wt process ! Regards, koen ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
