Алексей Карташов

Внезапно — я 6й в общем рейтинге. Офигеть xD

Я, кстати, у себя решил вопрос. Забыл сразу отписаться)

Во-первых, оказывается был включен APC-кешер. Нахер apc. Столько с ним магии было, вспоминать страшно (как пример).
Во-вторых, оказывается у меня в одном из плагинов был редирект через

header('Location: '.$url, true, 301);

Добавил перед редиректом

@session_write_close();

и всё — все проблемы как рукой сняло. Просто я писал данные в сессию в другом плагине, который срабатывал раньше, чем этот, с редиректом. И без session_write_close сессия не сохранялась.

Поищите у себя — может у вас тоже где-то в коде есть подобные тонкости.

Вот меня тоже подобные выкрутасы с сессиями порядком задолбали. У вас не нашлось стабильного рецепта?

Таймер чего?

И думается мне

Опять же — надо чётко понимать, а не додумывать) Ведите какой-нибудь лог, чтобы понимать — как часто делаются запросы. Хоть тупо в файл записывайте — не важно.

По сути так и есть, я логинюсь по 1 ссылке, парсю страницу по 2, и отправляю сообщение по 3

Тогда делайте как описано в той статье с хабра — открываете curl_init, делаете запросы к форуму сколько нужно, и только после всех запросов закрываете соединение curl_close (не забыв включить verbose-опцию в curl).

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

Здесь догадки, как вы понимаете, не уместны — всё нужно отслеживать, чтобы делать какие-то выводы.

Т.е. вы хотите сказать, что у вас в данный момент два практически идентичных (по структуре, дизайну и контенту) незазеркалированных сайта, которые находятся в выдаче по одинаковым запросам — один повыше, другой пониже, — и яндех их не зааффилировал?

Скажу 3 вещи:
1. Как вам такое в голову пришло — выкладывать 2 одинаковых сайта не заредиректив их и не склеив?
2. И вы ещё недовольны? Да вам радоваться надо! И пофиг — взломано оно там или нет.
Конечно это, скорей всего, до поры до времени, и рано или поздно один из них с треском из выдачи вылетит (по закону подлости, в выдаче останется тот, у которого позиции хуже).
И конечно, заниматься сейчас вангованием по комментарию и пытаться определить — что же вам там такого надо починить, чтобы всё стало хорошо — я не буду.
3. У вас очень аморфные и безмятежные конкуренты. Что за ниша? Какой регион?)

Скорее всего Антон спрашивал не про [[++base_url]], а про html-тег base :)
Хотя ты, скорей всего, подразумевал то, что ошибки бывают при использовании конструкции base href="[[++base_url]]" ?

Антон, в любом случае, если всё работает, то, какгрица, не трожь)
Если не уверен, то для понимания общих принципов, почитай вот это.

Я же рекомендую не использовать тег base совсем. А все ссылки, урл на картинки/скрипты/стили начинать со слеша (т.е. делать урлы абсолютными). Тогда никаких ошибок не будет и ссылки (в т.ч. якорные) 100% будут работать правильно.

Конечно, искаропки.

Вообще, для вашей задачи все эти танцы с keep-alive'ом для curl'а из php не имеют абсолютно никакого смысла, если для одного клиента вам не нужно делать больше одного запроса к стороннему сайту.
У вас же как — пользователь открывает вашу страницу (или отправляет post-запрос, неважно), сниппет через curl делает один запрос к стороннему сайту, получает и отдаёт данные клиенту и всё — php-процесс умирает. Как говорится — «php живёт, чтобы умереть». Для другого пользователя создатся свой отдельный php-процесс, который ничего про предыдущий curl-запрос предыдущего клиента знать не знает и знать не должен. Соответственно, пляски с keep-alive'ом бессмысленны.

Но вот если бы вам для одного пользователя нужно было бы слать несколько запросов на один и тот же домен (скажем, сперва авторизовать, потом отправить какие-то данные, потом получить данные с какой-то другой страницы от имени этого авторизованного юзера) и всё это в рамках одного php-процесса и подряд — то да, в keep-alive был бы смысл. Ибо на все эти три запроса не было бы повторных соединений, потому что curl держал бы лишь одно.

Нода работает по другому. Я сейчас не буду рассказывать про event-loop'ы, process.nextTick'и, таймеры и как оно вообще работает. Но общий смысл такой.
Когда поднимается веб-сервер на ноде, то создаётся один процесс, который висит, не умирает и ждёт запросов. Этот процесс и обрабатывает все запросы от всех клиентов, и вся работа происходит асинхронно. Именно этот нюанс не понимают php-разработчики при переходе на ноду и работают с ней не правильно (так, по-крайней мере, говорят. У меня проблем не возникло. Но коллбеки в коллбеках до сих пор вгоняют меня в уныние, да).
Вот здесь Илья Кантор (создатель javascript.ru) отлично раскрывает тему. Вообще, советую посмотреть весь скринкаст, если интересна нода, ибо он раскрывает многие (но не все) нюансы.

Так вот. Чтобы воспользоваться keep-alive'ом, я вижу только один вариант.
Поднимается веб-сервер на ноде, который слушает localhost на, к примеру, 3000м порту.
Этот веб-сервер на каждый запрос принимает ваши данные, которые нужно отослать на сторонний сайт, делает этот самый запрос на сторонний сайт и отдаёт ответ. А ваш сниппет, через curl, шлёт запросы на этот самый localhost:3000, который примет нода, и от неё же получает ответ.

Т.е. в вашем примере цепочка такая:
1. клиент шлёт данные;
2. сниппет их получает;
3. сниппет что-то отправляет через curl на сторонний сайт;
4. curl получает ответ от стороннего сайта;
5. отдаёт данные клиенту;
6. php умирает.

В примере с нодой будет вот так:
1. клиент шлёт данные;
2. сниппет их получает;
3. шлёт что-то в ноду через curl на localhost:3000 (и здесь, напомню, нода не будет тратить время на запуск и инициализацию, ибо она уже запущена и проинициализированна. т.е. всё происходит максимально быстро);
4. нода принимает данные и отправляет их на сторонний сайт;
5. нода принимает данные от стороннего сайта и отдаёт их;
6. curl этот результат принимает;
7. отдаёт данные клиенту;
8. php умирает, а нода продолжает жить.

Так и вот, собссна, вопрос — а где же здесь выигрыш? И это самый правильный вопрос!

На чём теряем:
— на отправку запроса в ноду;
— на получение ответа из ноды;
— проверку из php — запущен ли процесс ноды и, если нет, то запустить (либо fallback на текущий вариант — прямого запроса на сторонний сайт через curl, чтобы не тратить времени на запуск ноды).

На чём выигрываем:
— нода будет использовать keep-alive при получении запросов от curl (об этом есть в видео выше);
— нода будет использовать keep-alive при запросах к стороннему сайту (и то не факт — надо исходники копать).

И вот будут ли затраты покрывать выигрыш от keep-alive'а — это большооой вопрос.
В этом есть смысл только при наличии большого количества одновременных соединений. В вашем случае — количества пользователей, которые будут одновременно слать запросы через ваш сервис.

А по факту — если на вашем сервисе пользователи делают запросы реже, чем раз в 30 секунд, то всё это шаманство не имеет смысла вообще. Почему? Попробуйте догадаться сами :-)

А если чаще, чем раз в 30 секунд, то нужно тестировать. А чтобы протестировать — нужно написать готовый код, чего, сами понимаете, делать сейчас особо не хочется)
И вот если/когда код напишется и будет протестирован, то вполне может оказаться, что на этот комментарий я потратил гораздо больше, чем сэкономится процессорного времени за всё время существования вашего сервиса :)
А поскольку вы уверены в немощности вашего vps, значит (скорей всего) нет у вас на сайте такого количества одновременных пользователей и последний вариант — самый вероятный :)

Такие вот дела.

вот только мой VPS не справится

Чёйта? У меня на локальной машине, на винде, нодовский процесс, который ничего не делает, занимает 6,5 мегабайт памяти. Всё. Для вашей задачи (принимать и слать запросы) — не сильно больше. Любая vps'ка осилит.

А я бы взял ноду (nodejs). Но с ней с наскоку не справиться — слишком уж много нюансов для неподготовленного человека)

В яблочко! По всем пунктам :-)

касательно СЕО

SEO. Fixed.

Не. Деталей не помню, но там были какие-то приколы и ошибки нелогичные при упаковывании компонента.
Поэтому сперва addPackage, создаём/удаляем/обновляем таблицы, потом removeExtensionPackage, а потом addExtensionPackage.
Вот только в этом порядке при сборке пакета исчезли эти странные ошибки.
С тех пор эта копипаста у меня так и гуляет из компонента в компонент)

Не за что)

думал, что объект уже создан… вернее создается экземпляр класса при обращении по алиасу

С чего это вдруг?) Если xpdo будет на каждое обращение к новым объектам создавать все его зависимые объекты, то был бы просто ппц.
Поэтому, нужен объект — извольте его сперва создать)

кодо-текст посмотреть надо будет

Могу на словах описать что я хотел получить

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

А вот вы, похоже, не совсем понимаете как работают табличные объекты и связи между ними.

Изучайте документацию:
rtfm.modx.com/xpdo/2.x/getting-started/using-your-xpdo-model/creating-objects
rtfm.modx.com/xpdo/2.x/getting-started/using-your-xpdo-model/setting-object-fields
rtfm.modx.com/xpdo/2.x/getting-started/using-your-xpdo-model/working-with-related-objects

Ему не «set» не нравится. Ему не нравится, что в переменной $Data ничего нет.
Т.е. вам обязательно в коде нужно делать проверку типа такой:

if ($Data instanceof MyExtUser) {
  $Data->set('anyfield','any text'); 
  $Data->save();
}

Другой вопрос — почему в этой переменной ничего нет? Есть ли в вашей таблице получаемый объект? Рискну предположить, что нет)

Сперва создайте объект (либо через $User->addOne('MyExtUser', array(/*...*/)), либо $modx->newObject('MyExtUser')), а уж потом получайте его.

Добавьте в начало вашего сниппета вот это:

error_reporting(E_ALL);
ini_set('display_errors', 1);

Дальше смотрите ошибку. А пока не охота медитировать над кодо-текстом)

p.s. не забудьте на рабочем сайте удалить эти строки. Это только для отладки

Вот мой резолвер из одного проекта:
gist.github.com/antixrist/be29c8381214654af04e

Вам нужны вот эти строчки:
gist.github.com/antixrist/be29c8381214654af04e#file-resolve-tables-php-L38-L57

Подставьте вместо вот этого вашу связь:

$this->map['modUser']['composites']['Data'] = array(
    'class' => 'Userdata',
    'local' => 'id',
    'foreign' => 'userdata_id',
    'cardinality' => 'one',
    'owner' => 'local',
);

Ну и при копипасте не забудьте подставить свои пути/настройки.

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

Если что-то не понятно — спрашивайте)

Короче, снова переименовал.
Доступен по старому адресу: github.com/antixrist/lmims

блин)