1. Главная
  2. dimanjy

dimanjy: Комментарии

Главные вкладки

15 октября 2007 в 18:26

Огромное спасибо за, прямо-таки, мануал Smile У кого что тормозит? Ай-да ко мне в блог! Smile

До этого я думал, что исчерпал все возможности оптимизации Smile
- Апач снес вообще. Вместо него PHP в режиме FastCGI
- nginx на статику

14 октября 2007 в 23:54

VLAD_X, понимаю, Вы профессионал (сразу видно), но больно Вы усложняете. Задача у меня не собрать кластер, а собрать систему более производительную и за меньшие деньги. Так сказать, от бедности. Синхронизации для простого проекта никакой не нужно. Во всех хранилищах хранятся разные оперативные данные. При отказе одного из хранилищ данные не теряются, а всего-лишь падает быстродействие системы (memcache не работает - берем из БД).

14 октября 2007 в 13:18

VLAD_X, а Вы знакомы с nginx? Smile
Первые три пункта уже встроены в него, плюс модуль друпала для поддержки memcached сам начинает работать с базой, если memcached-сервер отвалился.
MySQL наружу открыт у многих крупных хостеров, проблем с безопасностью нет, если все нормально настроено. У memcached, конечно, надо только через файрволл жестко задавать ip, которым он доступен.

14 октября 2007 в 1:54

Вы знакомы с nginx? Я говорил о резервировании. При отказе одного из бэкендов сервер автоматом берет данные с "живого" или с локального. Отвалился MySQL - данные берутся с memcached-сервера. Отвалился memcached - из локального статического кэша. Какова вероятность отказа всех трех систем сразу, а? Smile К тому же у хорошего хостера валится все достаточно редко.

13 октября 2007 в 17:49

Shamaner, а про ssh-туннель можно подробнее? Что это такое и как работает?
SSH-то есть обычный, только вот mysql на другом хосте, и не дает, как я понял, удаленно подключаться.

13 октября 2007 в 0:50

Ursus, а Вы у них размещаетесь? Как бы посмотреть на phpinfo()... Теперь пока сам мемори лимит не увижу - не поверю Smile
Вообще хостеры мало информации дают. Лишь у некоторых можно подробнее узнать о площадках и серверах.

13 октября 2007 в 0:49

Я пока базу переливал - замучился! Лимит в 2Мб на загрузку зипованного дамба! У меня в зипе база весит 30 метров. А по одной табличке выливать - не дело. Вдруг забудешь еще какую-нибудь из них. Вы правы - это выживание Smile А хочется не отвлекаться на эти мелочи и просто развивать сайт.

20 сентября 2007 в 20:21

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

14 сентября 2007 в 13:59

Есть под это готовый модуль glossary.
Вообще, я друпалю около недели, но первое, что сделал - это пошел на страницу модулей и давай читать все описания подряд! Все, конечно, как говорится, "ниасилил" Smile и в голове уже каша, но зато примерно представляю, что есть, а чего нет.

14 сентября 2007 в 1:48

Я уже написал, только, наверное, не туда Smile

Нашел еще один баг там же. Он относится уже даже не к модулям, а, как я понимаю, вообще к ядру! При попытке сортировки таблицы по такому полю вновь выскакивает ошибка. На этот раз, докопался до /includes/tablesort.inc. Как раз отвечает за получение параметров сортировки. Функцию tablesort_sql подправил следующим образом:

6 сентября 2007 в 16:41

А кто каким образом запускает PHP как fastcgi?

Раньше я от Apache совсем отказался. Была у меня связка nginx + spawn_fcgi из lighttpd + PHP. Но последние два пункта работали крайне нестабильно и частенько nginx терял с ними связь. Выдавалось сообщение "Gateway timeout". Вылетало не часто, но когда работало, то работало очень быстро.

5 сентября 2007 в 13:23

Вот, кстати, идейка про Java-like PHP. На грани маразма, но все-таки:
Есть PHP-демон, который все время загружен и слушает HTTP-запросы на каком-нибудь 8181-порту. Веб-сервер проксирует на него все запросы. А сам демон - ни что иное как адаптированный движок Drupal, который все, что требуется, подгружает сразу в память и больше не выгружает, т.к. он - демон.
Как мысль? Завалится такая конструкция или жить будет?

5 сентября 2007 в 12:47

>kiev1 says:
>да, он кеширует и поэтому сайты летают даже быстрее друпаловских

Первый сайт у Вас ведь не на Drupal? Чего ж тогда их сравнивать?
Если б один был на Drupal + Smarty, а второй Drupal - Smarty, тогда да. Мои рукописные сайты тоже летают. Вопрос в том, как заставить Drupal летать с сохранением всех модулей и функциональности.

5 сентября 2007 в 12:41

>igdrasil@drupal.org says:
>вообще-то nginx - это полноценный http-сервер, причем выдает он статику с сумасшедшей скоростью,
>однако в случае с друпалом от него толку мало

5 сентября 2007 в 12:34

Речь же шла про Яндекс, а не про Гугль. Пиар там если и взялся откуда-нибудь, то уж точно не извне, а с исходной же страницы, поэтому если просто стереть страницы, то на них просто перестанет перетикать этот самый пиар. Что до Яндекса, так тот вообще может глубоко зафильтровать сайт за огромное число дублей. Проверено Smile

5 сентября 2007 в 1:09

Smarty - абсолютно ненужный шаблонизатор. Кэширует он в PHP-код, а вовсе не в статику. Заметного ускорения не получите. Интересные варианты могут быть получены только с использованием серверных решений: nginx, light httpd, memcached и все такое прочее.