LJ.Rossia.org fork development.

Apache compression

Fri, 14 Mar 2008 09:42:14 GMT

Я тут заметил, что при обращениях к LJR (и веротяно ко всему ленину) не используется сжатие. Mozilla морально готова пользоваться gzip compression и соответствующие запросы в Accept-Endodings прописывает. Насколько я понимаю - это надо где-то в настройках апача прописать, но я не очень компетентен в данном вопросе.

PS: http://www.websiteoptimization.com/speed/tweak/compress/

Comments

Mon, 13 Nov 2006 09:55:59 GMT

А есть такой вопрос - такая фича LJ, как customview у нас есть?
(http://community.livejournal.com/howto/16676.html)

Или это какое-то нововведение LJ?

Comments

Fri, 29 Jul 2005 19:18:04 GMT

Я в каком-то виде довел до ума свой вариант lj-gate.

Там причесан код (как мне кажется - довольно аккуратно) и избавлено от затеи с -10 минут (и фиксированного сдвига по времени). Ставить это сейчас не стоит, собака еще молодая, но я был бы признателен, если бы компетентные товарищи посмотрели на это дело и решили, что с этим делать дальше и стоит ли чего-то делать.

Известные проблемы: в режиме только гейтования все должно быть хорошо, но если пользователь запостит в LJ-шный дневник постиннг руками - вероятно будут проблемы с backdate. Так же syncitems идейно правилен (с ним логика куда прозрачнее), но видимо нежелателен по соображеням эффективности. Ну и возможны глюки.

Я бы не стал это сейчас посылать, но я завтра на несколько дней опять отваливаю и мне хотелось бы хотя бы минимального feedback'a.

Upd:Кстати - тормозит гейт, скорее всего, потому что он каждые 10 минут должен опросить все трансляции, а сделать это кроме как тупо спросив про каждую, никак невозможно. Я думаю, что это и жрет основное время - постит любой человек гораздо реже. То есть у человека максимум 5 постингов в день - а запросов на него выдается за день почти 6*24=144.

Так что syncitems вероятно можно и не выкидывать. А вот если дополнить функциональность syncitems возможностью спросить сразу про пачку пользователей я думаю, проблема вполне решится (его еще бы не помешало и нотификацией о удалениях дополнить - о новых комментах он вроде сообщает, хотя дока и утверждает, что это не реализовано).

README:
----------------------
lj-gate.pl - собственно главная программа
Util.pm - набор пользушных функций для работы с клиентским
протоколом LJ
LJDB.pm - набор функций для доступа к БД гейта
add.pl - переписан с использованием LJDB.pm

Изменения в формате БД:

добавлена колонка last_sync char (30) в таблицу rlj2lj.
Если в этом поле содержится NULL, в качестве времени
последний синхронизации берется текущий момент.

Соотвественно - должно быть достаточно ее создать
в таблице.

Другие изменения:пересажено на syncitems. Идеологически
это правильно, практически - вероятно добавит тормозов
(ибо каждая запись при этом берется отдельным запросом).

По-видимому, это надо херить, но сначала вероятно
есть смысл попробовать перелезть на плоский протокол.

Comments

Fri, 29 Jul 2005 18:13:47 GMT

Итак,
поставили наконец server-status,
и все стало гораздо яснее.
Вот типичный слепок со статуса
(типичный за последние сутки - я его
перегружаю постоянно)

Current Time: Friday, 29-Jul-2005 21:56:57 MSD
Restart Time: Friday, 29-Jul-2005 10:15:41 MSD
Parent Server Generation: 0
Server uptime: 11 hours 41 minutes 16 seconds
Total accesses: 115579 - Total Traffic: 478.7 MB
CPU Usage: u124.77 s5.48 cu.12 cs.05 - .31% CPU load
2.75 requests/sec - 11.7 kB/second - 4343 B/request
1 requests currently being processed, 11 idle servers

Srv	PID	Acc	M	CPU 	SS	Req	Conn	Child	Slot	Client	VHost	
0-0	15602	0/188/7683	_ 	3.08	47	50	0.0	0.61	33.40 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
1-0	15672	0/74/7570	_ 	1.47	11	72	0.0	0.41	30.07 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
2-0	15674	0/79/7573	_ 	1.50	149	13	0.0	0.29	29.41 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
3-0	15677	0/84/7577	_ 	1.86	29	48	0.0	0.39	31.02 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
4-0	15683	0/66/7558	W 	1.33	5	0	0.0	0.39	31.38 	129.234.4.1	lj.rossia.org	GET /server-status HTTP/1.0
 
5-0	15712	0/42/7535	_ 	0.96	23	2	0.0	0.27	29.11 	81.26.152.28	lj.rossia.org	POST /interface/flat HTTP/1.0
 
6-0	15733	0/32/7524	_ 	0.67	20	22	0.0	0.22	31.15 	81.26.152.28	lj.rossia.org	POST /interface/flat HTTP/1.0
 
7-0	15735	0/30/7025	_ 	0.30	23	13	0.0	0.10	29.29 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
8-0	15738	0/25/7021	_ 	0.47	36	13	0.0	0.17	31.46 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
9-0	15740	0/23/7015	_ 	0.48	31	52	0.0	0.14	29.33 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
10-0	-	0/0/6494	. 	9.81	489	14	0.0	0.00	26.46 	213.180.214.132	lj.rossia.org	GET /users/evolor/data/rss HTTP/1.1
 
11-0	-	0/0/6497	. 	10.39	327	1	0.0	0.00	25.02 	64.2.106.163	lj.rossia.org	GET /img/bluewhite/sidebarfade.gif HTTP/1.1
 
12-0	-	0/0/5996	. 	8.77	446	9	0.0	0.00	24.66 	213.180.214.132	lj.rossia.org	GET /users/tichy/data/rss HTTP/1.1
 
13-0	15623	0/149/5145	_ 	2.24	31	13	0.0	0.32	20.45 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
14-0	-	0/0/4992	. 	11.11	2266	1	0.0	0.00	20.13 	82.96.193.32	lj.rossia.org	GET /img/talk/none.gif HTTP/1.1
 
15-0	-	0/0/3997	. 	14.94	8907	6	0.0	0.00	18.21 	80.247.47.58	lj.rossia.org	GET /userpic/483/957 HTTP/1.1
 
16-0	-	0/0/2997	. 	8.02	8997	5	0.0	0.00	13.34 	217.15.150.143	lj.rossia.org	GET /userpic/1040/1757 HTTP/1.1
 
17-0	-	0/0/1997	. 	12.12	6548	1	0.0	0.00	8.35 	81.197.76.33	lj.rossia.org	GET /img/bluewhite/vline.gif HTTP/1.1
 
18-0	-	0/0/1499	. 	15.86	23305	50	0.0	0.00	7.36 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
19-0	-	0/0/999	. 	11.18	23306	1	0.0	0.00	4.01 	213.180.193.193	lj.rossia.org	GET /js/x_core.js HTTP/1.1
 
Srv	Child Server number - generation
PID	OS process ID
Acc	Number of accesses this connection / this child / this slot
M	Mode of operation
CPU	CPU usage, number of seconds
SS	Seconds since beginning of most recent request
Req	Milliseconds required to process most recent request
Conn	Kilobytes transferred this connection
Child	Megabytes transferred this child
Slot	Total megabytes transferred this slot

И что видно из сего?

А видно то, что 95% из всех процессов Апача
(из которых каждый, я хочу отметить, жрет по
50 мегабайт) заняты совершенно не тем.
А именно:

1. Примерно половина грузят статику

2. 40% занимаются тем, что считывают
записи LJ через клиентский интерфэйс.
Эти 40% жрут вчетверо больше ресурсов,
чем все остальное вместе взятое.

3. Из оставшихся 10% половина грузят
жабий скрип.

Приоритетные направления оптимизации из этого
совершенно ясны: это

1. Перевод статики на другой сервер (на днях
я сие обеспечу, если никто не возражает)

2. Избавление lj-gate от /interface/xmlrpc
который, судя по всему, совершенно сломан.
Надо исправить его на /interface/plain
либо (если это не улучшит ситуации)
вообще заменить на прямое обращение
к базе.

На сей момент гэйт жрет больше половины ресурсов
системы, при том, что им пользуются считанные десятки -
это категорически неправильно.

А в целом - мы имеем (при 1863 пользователях)
load average 0.30. Это при том, что при 1-1.5
она работает идеально, а при 4-5 работает
без особых проблем (хотя и тормозит).
То есть 20000 дневников, видимо, можно
у нас и без всякой оптимизации запустить;
просто не хочется ждать, когда начнутся
проблемы.

Такие дела
Миша

Comments

Sun, 24 Jul 2005 11:54:42 GMT

Я сейчас с подачи yushi@lj переписываю lj-gate. Что делаю -
помимо "причесывания" кода, пересаживаю его на syncitems, там
все можно сделать куда корректнее, чем сейчас, в частности -
update и delete там явно отличатся от create. И, безусловно, надо выкидывать
этот страх с -10 минут, а просто запоминать в базе
время последней синхронизации, отданное syncitems (он отдает именно
реальное время события, а не дату для постинга) и от него
и плясать в следующий раз.

Единственный вопрос - что делать с новыми пользователями - можно либо
стартовать от текущей даты, либо копировать дневник с самого начала.
Второе, наверное, не очень хорошо, хотя можно сделать параметром.

Сейчас я вынужден уехать на несколько дней - так что, если не горит,
- не трогайте его сильно.

Comments

Wed, 20 Jul 2005 19:13:06 GMT

Кстати, может быть, отрубить возможность включать lj_fif@lj во френды? Смысла то в этом нет...
Хотя вреда пока тоже.
UPD: а вред понял: от него действительно FOAF сильно перекашивает.

Comments

OpenID на помойку...

Wed, 20 Jul 2005 19:11:04 GMT

Вердикт, похоже, таков. Брэд опять сделал изменение, все стало немедленно криво. Работать с ним невозможно.
ИМХО, это дело стоит пока отключить. Нафиг. Иначе пользователи будут вопить.
Подождем стейбла.

Comments

Sat, 16 Jul 2005 19:32:06 GMT

Существует теперь специальная привилегия 'create_protected_com', созданная специально для того, чтобы обходить запрет на создание сообществ с запрещенными именами.
Сделано хаком в community/create.bml и добавлением информации о привилегии в базу.

Comments