Ядоблог

http://www.pickegg.com/wholesale/apad-tablet-pc-10-2-quot-arm-11-infotmic-x220-1ghz-512mb-4gb-android-2-2-mid-1-3mp-touchpad-with-gps.html

посмотрим что за зверь

Тестируем WordPress сайт утилитой ab:

ab -c 20 -n 200 http://lenta.iadlab.ru/

Что эквивалентно 20 запросам в секунду. Общее число запросов 200. Перед Apache стоит nginx, который принимает запросы и проксирует на apache в очередь.

Принцип работы XCache: предварительно компилируем PHP файлы в объектный код и сохраняем в памяти. При выполнении запроса линкуем нужные файлы из памяти и выполняем запрос.

Результаты без XCache:

Concurrency Level:      20
Time taken for tests:   51.226 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      10737600 bytes
HTML transferred:       10688600 bytes
Requests per second:    3.90 [#/sec] (mean)
Time per request:       5122.616 [ms] (mean)
Time per request:       256.131 [ms] (mean, across all concurrent requests)
Transfer rate:          204.70 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:   473 4935 1205.1   4900   10384
Waiting:      272 4544 1024.4   4588    9127
Total:        473 4935 1205.1   4900   10384

Результаты с XCache:

Concurrency Level:      20
Time taken for tests:   35.107 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      10737600 bytes
HTML transferred:       10688600 bytes
Requests per second:    5.70 [#/sec] (mean)
Time per request:       3510.692 [ms] (mean)
Time per request:       175.535 [ms] (mean, across all concurrent requests)
Transfer rate:          298.69 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.6      0       3
Processing:   418 3366 791.7   3310    6196
Waiting:      324 3015 625.8   3056    4991
Total:        421 3366 791.4   3310    6196

Вывод: время выполнения упало ~ вдвое.

Допустим у вас есть в коллекции групп массив операций которые входят в группу(также это может быть коллекция постов, в которую входит массив комментариев).

Задача: выдернуть операции, упорядочив их по id.

Черновик решения:

db.runCommand(
{ mapreduce: operations_groups, 
 map : function Map() {
this.operations.forEach
(
	function(z)
	{
		emit( this.id , z);
	}
);
}
 reduce : function Reduce(key, values) {
 
	return {values:values.sort()};
}
 finalize : function Finalize(key, reduced) {
	return reduced;
}
 keeptemp : false
});

Желающим потусить с админами и технарями сибири: http://sibadmin.org/.
Событие будет завтра.

Допустим у нас дома стоит сервер и для надёжности подведено несколько провайдеров. Как сделать доступными сайты этого сервера, если допустим основной провайдер упадёт?

Решение красивое =). смотреть тут:http://www.bloged.org/2009/07/nginx.html

Суть:
1. Берём VDS где-нить в ацко надёжном месте. например тут: TinyVDS
2. Настраиваем на нём проксирование nginx’ом запросов на нужные сайты (можно всех). Об этом я писал тут nginx, Двойное проксирование, реальный IP, только указываем наш mycloud вместо IP как получателя с чем-то вроде max_fails=3 fail_timeout=120
3. Настраиваем nginx на основном сервере, с кучей провайдеров
Наслаждаемся =)

Есть ещё решения? делитесь =)

upd, статья, вдруг сайт удалится:

Простая конфигурация

Допустим, вы разместили ваше приложение на нескольких серверах, пусть это будут три сервера с именами myserv-1.local, myserv-2.local и myserv-3.local, расположенные в вашей локальной сети (конечно же, на самом деле без разницы, где они будут размещаться). Для того, чтобы описать такое «облако» из трёх серверов в Nginx используется опция upstream:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
}

Описанное таким образом «облако» из нескольких upstream-серверов теперь можно использовать в качестве значения параметра proxy_pass, рассмотренного в предыдущей статье. Везде, где Nginx будет наталкиваться на ссылку (в нашем случае — «mySuperCloud»), он будет по алгоритму Round-Robin выбирать следующий сервер и выполнять обратное проксирование к нему и от него. Таким образом, теперь, описывая виртуальный хост, вы можете сослаться на ваше «облако»:

server {
  listen 192.168.0.1:80;
  access_log /var/log/nginx/proxy.log;
  location / {
    proxy_pass http://mycloud;
  }
}

Привязка клиента к серверу

Часто бывает нужно, чтобы один и тот же клиент, начав делать запросы к какому-то определённому серверу, не переключался на другие. Для этого в Nginx предусмотрена опция ip_hash. Если она определена, сервер будет запоминать IP-хеши клиентов и стараться проксировать каждого из них на один и тот же сервер.

upstream mySuperCloud {
  ip_hash;
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
}

Исключение сервера из «облака»

Если какой-то сервер по каким-то причинам вам необходимо отключить, чтобы Nginx не проксировал к нему клиентов, воспользуйетсь опцией down:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local down;
  server myserv-3.local;
}

Определение «веса» сервера

«Вес» сервера, грубо говоря, определяет насколько часто сервер будет использоваться. Например, вес сервера myserv-1.local равен 3, вес myserv-2.local равен 1 и вес myserv-3.local равен 2. В этом случае Nginx проксирует первых трёх клиентов к серверу myserv-1.local, четвёртого — к myserv-2.local, а пятого и шестого — к myserv-2.local, после чего круг начнётся сначала. Для определения веса сервера используется директива weight, значение по умолчанию которой равно единице.

upstream mySuperCloud {
  server myserv-1.local weight=3;
  server myserv-2.local;
  server myserv-3.local weight=2;
}

Автоотключение серверов

Если какой-то из upstream-серверов перестанет отвечать на запросы, то подключение к нему станет невозможным. Nginx в этом случае переключиться на использование следующего сервера из «облака», однако каждый раз будет пытаться подключаться к неработающему серверу, растрачивая время. При помощи директивы max_fails параметра server можно определить максимально-допустимое количество неудачных попыток подключения к upstream-серверу, после чего тот будет считаться нерабочим и запросы к нему прекратятся. По умолчанию значение этого параметра равно единице, то есть после одной неудачной попытки Nginx на определённое время прекратит попытки новых подключений с нерабочему серверу. Это «определённое время» определяется значением опции fail_timeout, по умолчанию равным 10 секундам.

upstream mySuperCloud {
  server myserv-1.local max_fails=3 fail_timeout=120;
  server myserv-2.local;
  server myserv-3.local;
}

Резервные серверы

Под понятием «резервный» в Nginx выступает сервер, который используется тогда, и только тогда, когда все «не резервные» upstream-серверы определены как нерабочие, т. е. не отвечающие на запросы. Резервные серверы отмечаются с помощью директивы backup:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
  server backup-server-1.local backup;
  server backup-server-2.local backup;
}

Предложите решение в комментах.

Задача: хранить Игроков

Варианты решения 3 штуки(смотри картинки снизу. Слева объектная структура данных, справа способ хранения):

1. В одной таблице

2. Разделять по типам игроков и хранить в «типизированных» таблицах

3. Смешанный стиль — одинаковую информацию в главной таблице и типизированную информацию в типизированных таблицах