HowTo configure SST-WebServer - WebServices
bonndias
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).
Douglas Swartz
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
Sebastian Heidbrink
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
bonndias
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