What are your experiences/advices with/for tuning/configuring the performance of the SST-Webserver.
Actually we got pretty fast hardware but we have the impression our application should benefit more than it does. Our application is using the WebServices feature to get requests and then uses TCP/IP to call another Smalltalk application, which does the work. The connections between the application with the webserver and the one which does the work, stay open all the time. We have a mix of short running requests of about 20ms and long ones lasting several seconds. What we did so far is increase the listenBacklog of the HTTP-Configuration and increased the number of server processes like this: (SstInvocationHandler schemeRegistry at: 'http') numberOfServerProcesses: 200; restartMode: SstConstants::SstRestartMode; errorTrapLimit: 200; marshalWorkerManager: (SstWorkerManager high: 30 low: 2 strict: true). -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/-HZf-2-o4FQJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Hello bonndias,
Tuesday, March 20, 2012, 9:01:23 AM, you wrote: > What are your experiences/advices with/for tuning/configuring the > performance of the SST-Webserver. > Actually we got pretty fast hardware but we have the impression our > application should benefit more than it does. Our application is > using the WebServices feature to get requests and then uses TCP/IP > to call another Smalltalk application, which does the work. Remember that VA Smalltalk images are single threaded from the perspective of the operating system. Thus, the image "that does all the work" only gets the benefit of the processing power of a single core regardless of the number of cores on your machine. You don't say what OS you're running on, but it should be pretty easy to see if cpu availability for that image is your bottleneck. Otherwise, hopefully you have your app instrumented well enough so you can determine where the bottlenecks are. In my experience, changing settings without knowing what is throttling your performance is unlikely to produce very good results. -- Best regards, Doug Swartz -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Hi bonndias,
Douglas is right. You bottleneck might not be the CPU. Some CPUs are even slower in respect to Mhz power than "older" ones because they benefit more from multi processing than from the single speed of a single core. Nowadays is not always the CPU, but the network connection, the ram, or the harddrive which might be the bottleneck. If you have a lot of file io going on , you may want to have a look at a introductions of SSDs as a faster replacement of you harddrives, of even introduce shared memory mapped files. But before you spend any money you may and should want to trace your application using the EsbBench which you can find in the ENVY ES/Stat configurationsmap. It will help you best to find the real issues, if there are any. Happy searching and good luck Sebastian Am 20.03.2012 17:38, schrieb Douglas Swartz: > Hello bonndias, > > Tuesday, March 20, 2012, 9:01:23 AM, you wrote: > >> What are your experiences/advices with/for tuning/configuring the >> performance of the SST-Webserver. >> Actually we got pretty fast hardware but we have the impression our >> application should benefit more than it does. Our application is >> using the WebServices feature to get requests and then uses TCP/IP >> to call another Smalltalk application, which does the work. > Remember that VA Smalltalk images are single threaded from the > perspective of the operating system. Thus, the image "that does all > the work" only gets the benefit of the processing power of a single > core regardless of the number of cores on your machine. You don't say > what OS you're running on, but it should be pretty easy to see if cpu > availability for that image is your bottleneck. > > Otherwise, hopefully you have your app instrumented well enough so you > can determine where the bottlenecks are. In my experience, changing > settings without knowing what is throttling your performance is > unlikely to produce very good results. > > -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
OS for our new Hardware is Windows 2008. The new hardware is a Xeon CPU E620 @2.40 GHz (16 CPUs) with 32GB RAM. The Old one is an AMD 64 (8 CPU) ~2.1GHz with 32GB RAM too. It's OS is Windows 2003 x64.
Both of the applications mentioned above run on the same hardware to avoid network traffic. When we load test our application we see, that from our application running the SST http-server a maximum of ~20 sockets is opened to the other application. We open these sockets on demand and they stay open. But regardless how many clients we simulate not more than these 20 connections are established. That means too, that increasing the number of simulated clients does not increase the total number of processed requests. Only effect is, that each request takes longer. But our hardware is more or less bored. We altered the listenBacklog, because of errors we got, when we increased the number of clients. The errors are gone now and all requests end without error. We have the feeling, something is blocking or queuing the incoming SOAP requests too bad and prevents to establish more connections to our second application. Our second application is a Client/Server application running for years now and performing good enough for more than thousand clients. Do you have similar experiences? What should we try to improve the situation? Regards bonndias -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/pRwcs0z_B1EJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Free forum by Nabble | Edit this page |