On Fri, Apr 5, 2013 at 2:30 AM, Steve Vinoski <vinoski@ieee.org> wrote:


On Thu, Apr 4, 2013 at 10:21 AM, Martin Dimitrov <mrtndimitrov@gmail.com> wrote:
Our app is using embedded YAWS server. I played around to do performance tests with OpenSTA. The setup is 30 virtual users, all pass through the test at once. OpenSTA is on virtual (VMWare) Windows XP machine and the Erlang app on a Windows 8 machine which has 4 cores and 8GB of RAM.

OpenSTA reports 5 seconds response time for 10-15 requests but our own in-app performance measurement shows nothing even close - the longest request takes 200 milliseconds and it measures the whole message handing by calling now/0 at entrance and timer:now_diff/1 before returning.

I tried to profile YAWS with eprof. Firstly, I saw 97% of the time was spent in yaws_logger module. I turned access_log to false and now all YAWS modules spend 0% according to eprof. But there is no improvement in the response time according to OpenSTA.

I know this question is too vague but still doesn't hurt to ask :)

You might try tracing. Can you get an interactive Erlang shell into your system? If so then issue the following commands:

dbg:tracer(), dbg:p(all, [call, timestamp]).
dbg:tpl(yaws_server, aloop, []).

Then hit the system with one client request. You should see some trace details on your Erlang console, including timestamps for the call in question. That function is recursive and it includes pretty much all of the server processing per request, so it's a quick way to help narrow down where the time is going.

To stop the tracing: dbg:stop_clear().

Just to clarify this a bit: the purpose of hitting the system with just a single request is to see how long the yaws_server:aloop function takes under a no-load scenario. If you issue just one client request, the dbg setup I described will detail two aloop calls, each providing a timestamp. Just subtract the timestamps to get a timing for the aloop function.

BTW you're not somehow serializing your requests, are you? This could definitely cause scalability issues as well as head-of-line blocking for requests. Read one of my "Functional Web" columns for more details:

http://steve.vinoski.net/pdf/IC-Erlang_Web_Process_Bottlenecks.pdf

--steve