On Fri, Apr 5, 2013 at 2:30 AM, Steve Vinoski <vinoski@...> wrote:
> On Thu, Apr 4, 2013 at 10:21 AM, Martin Dimitrov <mrtndimitrov@...:
>> 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: