В една тенджера се слагат 3 настъргани моркова и една нарязана глава лук. Добавя се олио на око и 2 чаши (cups) вода. Тенджерата се слага на котлона да кипне. Добавя се сол на вкус. Добавя се 1.5 чаша (cup) ориз и бърка бърка докато попие водата. Когато водата е почти попила, се добавят 1.5 чаша (cup) смляни домати от консерва. Добавя се джоджен на вкус. Бърка се докато ориза попие водата. С това плънката за сармите е готова.
На зелевите листата се махат дебелите части за да могат да се завиват по-лесно. В тепсия се слага малко олио на дъното и почват да се завиват сармите. 1 листо = 1 сарма. На една сарма се слага 1 или 2 пълни лъжици плънка в зависимост от големината на листото. Завиват се 4-те края и сармата се слага в тавата със завитите краища отдолу. Добавя се една чаша гореща вода в тавата и се слага във фурната да се пече на 200 ℃ (400 ℉ ) градуса докато водата изчезне.
(Update 8/25/2017: A day after this was posted, traffic shaping on Mac OS was officially supported, however if you are using Docker it will not work as Docker runs in a linux headless agent.)
Recently at NerdWallet we’ve started using SpeedCurve to have a historical record of our WebPagetest results and shiny graphs to help visualize. It’s been a really great tool in terms of measuring performance for a large production website.
However sometimes it can be useful to have an even tighter feedback loop when you are iterating on performance, to get a sense of what works and by how much.
WebPagetest is awesome but I found the documentation a bit lacking so I thought I’d share into my experience in setting up a WebPageTest private instance for local development.
Docker Setup
WebPageTest has two components that need to be in sync with each other, the server and the agent. The server handles the frontend app for WebPagetest and the agent actually runs the tests. The agent polls the server for tests to run, and posts to an endpoint on the server. To spin these up, the WebPageTest folks have created Docker images for both:
If you aren’t super familiar with Docker (as I wasn’t), I’d recommend going through the tutorials to familiarize yourself. After you’ve gotten setup you’ll want to pull down the WebPageTest server and agent images.
After pulling down the images you can create the containers.
Run the server
# -d runs the container in "detached" mode in the background # -p specifies the port to expose. # --rm will remove the container upon exiting $ docker run -d -p 4000:80 --rm webpagetest/server
Just after running the server, you should be able to browse to http://localhost:4000 and see the webpage test private instance page to confirm it’s up.
NOTE: Feel free to specify ports other than the one(s) I’m using.
Run the agent
# --network="host" allows the agent to communicate with the server container # -e specifies an environment variable. WPT requires `SERVER_URL` and `LOCATION` be defined. $ docker run -d -p 4001:80 \ --network="host" \ -e "SERVER_URL=http://localhost:4000/work/" \ -e "LOCATION=Test" \ webpagetest/agent
The SERVER_URL should be set to <your server>/work/ — it denotes the URL for the agent to poll. The LOCATION should match one of the locations defined in settings/locations.ini in the WebPagetest server. These define the parameters for that agent you are running (e.g. browsers supported, label, and other goodies). These environment variables are used in the startup script of the wptagent python app.
NOTE: The agent will throw errors if it can’t communicate with the server. Try running the above command without detached mode (remove the -d) and it will spit out errors if there are any.
Start it up
Head over to http://localhost:4000 . You should see the frontend for WebPagetest and on the surface things look good. Right? Let’s check. There’s a built in configuration check if you hit http://localhost:4000/install
What you should see at `http://localhost:4000/install`
If your agent is able to communicate with your server, you should see an agent connected for the Test Location. Easy enough.
However if you’re on OS X like I am, there’s still a bit more work needed.
You can remove traffic shaping by doing two things — setting a dummy value for connectivity in your settings/locations.ini file on your server, and setting --shaper none when the agent is starting up.
I’d recommend creating a new Docker image based on the original WPT agent/server images but with modifications to the configuration.
Server
Setup a new folder that has two files, a Dockerfile and a locations.ini
Dockerfile
FROM webpagetest/server ADD locations.ini /var/www/html/settings/
This defines a new docker image that pulls from webpagetest/server , replacing the locations.ini file with one that will work for OS X, particularly setting connectivity to remove traffic shaping.
# -t defines the name we are giving to this image $ docker build -t local-wptserver .
Agent
Setup a new folder that has two files, a Dockerfile and a script.sh
Dockerfile
FROM webpagetest/agent ADD script.sh / ENTRYPOINT /script.sh
script.sh
#!/bin/bash set -eif [ -z "$SERVER_URL" ]; then echo >&2 'SERVER_URL not set' exit 1 fiif [ -z "$LOCATION" ]; then echo >&2 'LOCATION not set' exit 1 fiEXTRA_ARGS=""if [ -n "$NAME" ]; then EXTRA_ARGS="$EXTRA_ARGS --name $NAME" fipython /wptagent/wptagent.py --server $SERVER_URL --location $LOCATION $EXTRA_ARGS --xvfb --dockerized -vvvvv --shaper none
This defines a new docker image with a copy of the existing WPT entrypoint script that tacks on the --shaper none flag.
Make sure script.sh is executable:
chmod u+x script.sh
And now we can build our agent image:
# -t defines the name we are giving to this image $ docker build -t local-wptagent .
Start it up (for real)
Alright now we should be able to start up our local copies. You may need to first stop the existing docker containers.