On 09/16/2010 02:45 PM, Pranav Desai wrote:
On Thu, Sep 16, 2010 at 12:33 PM, Leif Hedstrom<[email protected]> wrote:
On 09/16/2010 01:26 PM, Pranav Desai wrote:
Hi!
I am running a load test with some video files to see . I am using
curl-loader to generate the load. I have modified it to add a random
number to the URLs before sending so I can test with a single URL and
still stress the cache. The webserver is a lighttpd server with
rewrite rules to translate the random strings back to a common URL.
The URL is essentially a 15MB video file. I can provide more details
on the setup if needed.
Ok, I've created https://issues.apache.org/jira/browse/TS-441 with this
information. If you can find a core file (or, run traffic_server under gdb),
and get a stack trace, that would be very helpful. Also, when it crashes,
you might get a stack trace in /var/log/messages and/or one of the log files
in the .../var/log/trafficserver directory.
Will do that.
Is there an architecture diagram or doc some where that briefly
describes how the system works especially in terms of the roles of the
processes like traffic_manager and traffic_server and how they
interact, communicate. How the threads get the request, who runs the
event loop etc. Even a general block diagram would work for me. It
will of great help in understanding the system.
Well, the admin guide (http://trafficserver.apache.org/docs/v2/admin/)
should give some ideas on how the system overall runs (processes etc.),
and the developers guide ( http://trafficserver.apache.org/docs/v2/sdk/)
will give some ideas how things works under the hood.
That much said, I can tell you what the three processes does (big picture);
1. traffic_cop - This process starts the traffic_manager process, and
it's primary task is to verify that the traffic_server process is
responding to a built-in health check. If it doesn't, traffic_cop
will kill the traffic_server process.
2. traffic_manager - This process is responsible for various "admin"
tasks, and also implements the (defunct) WebUI. In addition, it
binds the "listen" port(s) that the server will accept requests
on, and start the traffic_server process. If this process dies
(either crashes or killed by traffic_cop), traffic_manager still
has the ports bound, and will immediately restart traffic_server.
3. traffic_server - This is the primary proxy server process. It will
run <n> number of worker threads (net-threads), where n is
configurable but defaulted to something reasonable based on the
number of CPUs. It also runs <m> I/O threads, by default 4 threads
per disk spindle (but this is also configurable, and 4 is probably
to small in many cases). In addition, there are a few "helper"
threads for things like logging etc.
Cheers,
-- leif
