"drupby" wrote:

или у тебя получилось его установить только локально? ну тогда поищи в интернетах - там полно статей по установке xdebug и его конфигурированию

Спасибо за совет, но я вполне умею пользоваться и xdebug и xhprof, и соответственно знаю, когда что лучше применять, поэтому и пытаюсь донести эту информацию.

Если расставить какие-нибудь знаки препинания, то возможно, вопрос и обретёт смысл. Но пока, я что-то понять его не могу. А может и с ними не смогу.
Может переформулировать доступнее?

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

В разработке я тоже xdebug использую, т.к. это ещё и отладчик. И проблемы быстродействия не важны.

У вас нет одной из нужных таблиц в БД. Как это произошло - вам виднее.
Вот вам SQL, который создаст эту таблицу:

Ну для этого придуман профайлинг - посмотрите в сторону xhprof, например.

"F0xshp10n" wrote:

chown -R www-data:username /home/username/www

Напрасно. В крайнем случае, надо было наоборот- username:www-data и дать дать g+w, куда надо писать веб серверу.

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

1000 записей из которых надо выбрать случайные это очень мало - это не нагрузка. Можно было бы париться, если бы записей были миллионы, и ещё были бы сложные join. Тогда да, надо было бы оптимизировать, выбирая сначала случайные id, потом данные по ним.

"drupby" wrote:

и зачем ему на локальном сервере ftp ?

Настраивается элементарно, и позволяет просто решить проблему, не делая лишних допущений.

У вас по какой-то причине очень долго выполняются скрипты - более 30 сек.
Исправить можно в принципе увеличив таймаут, но это неправильное решение. Разгадку надо искать в скриптах.
А тут вам, видимо, придётся разбераться самостоятельно.

Собственно не так у вас как минимум то, что не был подключён javascript необходимый для запуска jwplayer('mediaspace')
Ну и конечно разумнее использовать одно из готовых решений для вставки видео, а не пытаться сделать что-то в шаблоне с нуля, если уж у вас не статичная html страничка.

Файлы залиты от рута. Веб сервер, работающий от www-data, прав на запись не имеет.

Как поступить:
Сменить владельца файлов на не привелигированного пользователя. И заливать впреть под ним. Вообще под рутом не надо делать чего-либо, что можно сделать не под рутом.
Поднять ftp сервер.
В настройках drupal прописать соответствуюий сервер, логин.

Не надо давать права на запись пользователю, под которым запущен веб сервер куда-либо кроме sites/*/files/ - не надо привыкать к плохому.
Естественно не надо ставить 777 на папки и файлы.

Ну и на всякий случай: page.tpl.php~ это резервная копия. На стороне сервера обычно можно зачистить, еслинет никакой специальной идеи зачем это там лежит.

Дело в том, что fcgid упёрся в лимит на количество запускаемых процессов php.

"sg85" wrote:

Я как-то не особо разбирался со сфинксом(если быть точнее, вообще не вдавался в подробности), но разве он индексы хранит не в БД?

Нет, не в БД. Я выше об этом писал.
В нашем применении сфинкс вообще с БД напрямую не связан - Search API кормит его текстами. Sphinx строит индексы(они хранятся в файлах, в специальном формате). Потом Search API делает к нему запросы.

Sphinx интереснее и скоростью, и более скромным потреблением ресурсов при прочих равных - это нативное приложение на C.
По возможностям он, конечно, уступает Solr, но чего не хватает применительно к поиску в drupal?
Search API с ним работает, соответственно, и модули работающие с Search API должны, они же работают уже не на прямую с бекэндом поиска...

Ну и лечь база не должна - с чего бы. Сфинкс работает со своими RT индексами, в Search API, а не совместно с mysql, и базу не положит, ни при поиске активном, ни если упадёт сам.

Кстати, не совсем по теме статьи, но заголовок про solr и слабые vps немного издевательски выглядит.
Java приложение со всей оснасткой для запуска довольно прожорливо, для слабой vps.
Так что как мне кажется, тут стоит ещё рассмотреть альтернативу в виде того же sphinx, например.

"azsx" wrote:

ну и просто, метод виртуализации на настройки сервера не особо влияет. Можно и xen'ом устроить гостям сладкую жизнь, а можно и open vz отлично настроить

"Artu" wrote:

Да так не просто покопаться, а попробовать каждую функции на практике нужно на пример проникновения.

Этот список имеет своей целью запретить выполнение внешних комманд прежде всего, так что особо и копаться не придётся.

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

Почитайте error log, как и указано в ошибке. И скопируйте его сюда, если будет не понятно... Без данных из него, вам никто помочь не сможет.

Такое может быть, если у сервера перегружены диски, или если перегружен сервер БД.

"Evil_inc" wrote:

описанная проблема возникает на локалном сервере при стандартных настройках

Что у вас из себя представляет локальный сервер?

Зачем пытаться получить все эти данные в одном запросе?
Разбейте задачу на несколько запросов. Будет проще и вам и mysql.

Тогда вы просто берётесь не за своё дело, и нормально с таким подходом ничего настроить не получится.
Тем более, что вам как разработчику, уж покопаться в документации PHP сам бог велел.

Пожалуй не стану, но вместо этого посоветую - посмотрите документацию по функциям php, и напишите свой.
Это будет куда полезнее. А потом, можем его обсудить.

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

"misterpronin" wrote:

curl_exec, curl_multi_exec

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