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

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

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

14 июля 2009 в 14:39

"<a href="mailto:kayo@drupal.org">kayo@drupal.org</a>" wrote:
Кэширование объектов node имеет смысл, если включено много модулей, использующих nodeapi, поскольку вы избегаете выполнения десятков запросов в node_load. Если это оказывается не эффективно, можно отключить.

13 июля 2009 в 23:02

Не имеет смысла:
* Кэширование объектов node;
* Кэширование страниц материалов (node/$nid);
* Кэширование комментариев;
* Сохранение в кэше установленного заголовка, breadcrumb, подключенных стилей, скриптов;

не пойму в чем отличие:
* Кэширование страниц материалов по терминам таксономии;
* Кэширование лент терминов;

9 июля 2009 в 14:18

Есть одно хорошее правило "Пока работает лучше не трогать".
Однако подумать умом стоит.
Ну что Вам даст обновление?

Тут я вижу три варианта:
1. Закрытие дыр в безопастности.
2. Улучшение производительности
3. Починка багов.

Только первый вариант стоит рассматривать как причину к обновлению и только при условии, что в описание "дыры" попадает Ваш сайт.

За второй и третий вариант нужно брать деньги как за дополнительную работу.

9 июня 2009 в 17:48

Я полностью не согласен с Владом.
Отфутболивать заказчиков нельзя ни в коем случае.
С заказчиками нужно поддерживать легкие и приятные отношения.
Даже если я занять по горло и не могу в данный момен заняться другим проектом, то я говорю "Сделаем, но по позже." Если заказчик согласен ждать то будет работа, если нет, то у него отстанется приятное впечатление от вас.
Это первое.

4 июня 2009 в 23:27

Интерес и деньги, Вы сравниваете теплое с мягким.
Есть интерес, и есть деньги. Для многих эти области никогда не пересекаются. И может быть это и к лучшему, т.к. должна быть работа, и должно быть хобби.

4 июня 2009 в 14:57

Там много тонкостей.
Порядок то же имеет свое значение.
Допустим у Вас есть таблица (table_name) с двойным индексом (key_1, key_2)
Вот в этих случаях индекс не будет использоваться:
SELECT * FROM table_name WHERE key_2 = "something"
SELECT * FROM table_name WHERE key_2 = "something 2" AND key_1 = "something 1"

Указывать ключи в условии нужно в том порядке, в каком они определены в индексе:

SELECT * FROM table_name WHERE key_1 = "something 1" AND key_2 = "something 2"

3 июня 2009 в 12:02

"Valeratal" wrote:
разница в том, что сначало проверили на "опубликованность" ?

Разница в использовании индексов.
Курите мануал по MySQL. Конкретно вот эта глава про оптимизацию запросов:
http://dev.mysql.com/doc/refman/5.0/en/optimization.html

Пользуйтесь инструкцией EXPLAIN

29 мая 2009 в 15:13

"kyky" wrote:
Это не бред, это очевидность.

Да, да, в большинстве случаев это очевидность.
Однако, даже если говорить о своих модулях, то у Друпала есть свое чистое и понятное API.
Работать с API и работать с самописом в котором API и не пахло согласитесь "две большие разницы".

29 мая 2009 в 1:53

"Ilya1st" wrote:
Если оплачиваемую поддержку(которая клиенту нужна, хотие вы этого или нет) считать сажанием на иглу.....
У вас есть другой вариант? Сделать проект и забить? так и клиент через месяц на него забьет потому как некому в конторе им заниматься. им не до того.

Вы немного не поняли, здесь идея не та. Здесь идея чисто программерская.

8 мая 2009 в 12:51

Автору топика: Вы хоть бы немножко раскрыли тему. В результате чего достигается оптимизация?
Вот о чем написано здесь: http://fourkitchens.com/pressflow-makes-drupal-scale

1. Поддержка репликации базы данных. Для этого используется специальный уровень абстракции БД. Который, кстати говоря, обещают внедрить в D7

2. Поддержка реверс-прокси кеширования Squid и Varnish. Обслуживаются скрипты и картинки для всех, и страницы полностью для анонимов.

7 мая 2009 в 1:11

"v1adimir" wrote:
корректнее сказать -- один IP = только один интерфейс

интерфейс -- это "физическая" точка доставки пакетов с одного IP-адреса на другой. это может быть компьютер, роутер, какая-нибудь виртуальная программная сущностью... но route-таблицы в каждую любую секунду ведут пакеты до однозначно отпределенного "физического" места.

6 мая 2009 в 13:14 
C:\Users\esk>nslookup www.google.com

Server:  videoserver.mshome.net

Address:  192.168.0.1



Неофициальный ответ:

Name:    www.l.google.com

Addresses:  74.125.79.147 - 190 сайтов

          74.125.79.103 - 190 сайтов