5 июня 2015 г., 17:18

Помогите разобраться что не так

Что не так делаю? при limit 10 все махом срабатывает и происходит то что надо при Limit 100 15 сек и опять нормальный результат при limit 700 все вешается и ни каких результатов не получаю и через 30 минут
<?php $q = $modx->newQuery('modResource', array('parent' => 3, 'deleted' => false,)); $q->limit(1000); $q->sortby('publishedon','ASC'); $resource = $modx->getCollection('modResource', $q); $output = '<table><tbody>'; foreach ($resource as $res) { $output .= '<tr><td>'.$res->get('publishedon').'</td><td>'.$res->get('id').'</td>'; $z=0; while($z++<22){ if($z<10) $tvname = 'signal0'.$z; else $tvname = 'signal'.$z; if($z==22) $tvname = 'signalReal'; $tv = $res->getTVValue($tvname); if(!$tv) $tv = '----'; $output .= '<td>'.$tvname.' : '.$tv.'</td>'; } $output .= '</tr>'; } $output .= '</tbody></table>'; print_r($output);die();
слишком большой объем памяти скорее всего
Понятно что ресурсов не хватает но что не так? как то такое можно же реализовать сейчас у меня 700 рессурсов у каждого 22 TV параметра мне нужна таблица этих ресурсов с параметрами да еще и обработать надо в каждой строке TV и вывести уже новые результаты в строку по идее всего то ничего данных то… помогите… плиз…
Хм, а в чем преимущество, просто выбрать и вывести все ресурсы не проблема, а вот когда начинаешь с ТВ маятся все виснет пока ручками маюсь по одной ТВ а не сразу все 22, работает кое как.
разница в том, что памяти гораздо меньше используется. По крайней мере, уже на память можно будет не грешить. Ну и как вариант — расширить modResource. http://habrahabr.ru/post/253737/ Это точно поможет :)
Чистая таблица с 10 полями, 1000 строк одновременного вывода сильнонагружает модкс, а тут 22 тв параметра это же с ума сойти… которые отдельно достаются. считай 700*22 это 14к+ запросов к базе. Вообще да, надо расширять modResource и почти все ТВ поля переносить в отдельную таблицу
я бы в данном случае migx использовал бы, так как все TV вроде однотипные, то по-моему проще из 22 одно, хоть и с JSON массивом сделать. Да и запрос лучше с JOIN-ом писать т.к. 1 запрос пусть и громоздкий лучше чем 1000.
<?php $query = $modx->newQuery('modTemplateVarResource'); $query->innerJoin('modResource','modResource','modTemplateVarResource.contentid=modResource.id'); $query->where(array( 'modResource.parent' => 2, 'modResource.deleted'=> 0, 'modTemplateVarResource.tmplvarid'=>1 )); $Tv = $modx->getCollection('modTemplateVarResource',$query); foreach($Tv as $key){ print($key->get('value')); print(' || '); }
Отвечу, рассчитывая на комментарий Николая, если я неправильно что-то пониманию. Если нужно именно вывести данные, пусть и с обработкой перед выводом, то выгоднее не использовать getCollection, а выбрать через fetchAll(PDO::FETCH_ASSOC), чтобы не создавать объекты. Конечная цель — массив с выбранными документами. TV можно выбрать вторым запросом, используя уже полученный массив, к нему же и присоединить результаты. Дальше уже в цикле обрабатываем и выводим.
Если нужно именно вывести данные, пусть и с обработкой перед выводом, то выгоднее не использовать getCollection, а выбрать через fetchAll(PDO::FETCH_ASSOC)
Именно это и делает метод getIterator
Почти, там fetch, а не fetchAll.
то выгоднее не использовать getCollection, а выбрать через fetchAll(PDO::FETCH_ASSOC)
В большинстве случаев да.
TV можно выбрать вторым запросом, используя уже полученный массив, к нему же и присоединить результаты.
Можно и сразу запрос сформировать, используя leftJoin(). Просто сколько будет нужных TVшек, столько и джоинов выполнять, указывая в условии ID-шник добавляемой ТВшки.
Именно это и делает метод getIterator
Не совсем. Во-первых, не fetchAll() используется, fetch(), так как на каждую итерацию идет выборка только одной строки из БД. Во-вторых, getIterator получая очередную строчку данных, набивает ее в конечный объект. А формируя запрос и выполняя fetch() самостоятельно, мы просто оперируем полученными данными. Это во многие разы снижает потребление ресурсов.
У меня только один вопрос: а почему не использовать getdata-процессоры? Как раз для таких задач они же и были написаны.
которые отдельно достаются. считай 700*22 это 14к+ запросов к базе.
Проблема-то не в MODX, а в вас, точнее в вашем подходе. Нафига выполнять 22 запрос к ТВхам на каждый документ? А еще интересно нафига вообще сразу 700 документов получать, а еще и к ним по 22 запроса на каждый делать? Пересматривайте свой подход к работе. Так можно любое нормальное приложение испортить.
Я Это и имел ввиду, что не правильно подходит к решению задачи) я бы так не стал делать :D
Я бы с удовольствием их использовал, но не умею может приведете пример как?
А как вывести в таблицу все ТВ для всех ресурсов?
Еще такой вопрос, с чем работать будет быстрее, удобней и правильней если все 22 ТВ перенести в MIGX ТВ 1 2000 документов с одним MIGX 2 Один документ с 2000 MIGX строками, где наши 22 значения
ИМХО, если у вас там так все объемно, то надо было писать индивидуальные интерфейсы. Если с этим сложности, то зачем тогда вообще браться было за столь сложный проект? Как обычно, из серии «достаньте мне грунт из космоса». Я в таких вопросах не помощник.
:) ну с таким подходом можно сидеть с пустышкой во рту и «агу-агу» всю жизнь говорить, то есть если не умеешь водить машину, то и не берись — ЭТО СЛОЖНО! АЙ-АЙ. или вас мама сразу «умным» и «всёзнающим» родила?! Мне не повезло, я нигде не учился программированию, до чего сам дошел, то и знаю, да еще вот такие форумы помогают — СПАСИБО, ну если по рукам не бьют с фразой — ВАМ ЭТО СЛОЖНО, НЕ БЕРИТЕСЬ, ЭТО ДОСТУПНО ТОЛЬКО НАМ — «УМНЫМ»… ТОЛЬКО МЫ ЗНАЕМ КАК БРАТЬ ГРУНТ ИЗ КОСМОСА… ХА-ХА… К чему — эта фраза вообще? не хотите по существу ответить — не надо, а учить как мне жить, за что браться, за что нет — не стоит я думаю ;)!
На счет объемности, как раз на мой взгляд не выглядит объемно, эти 22 параметра могут быть или 1 или 0 других значений не бывает по этому не ожидал что буду проблемы с их обработкой а вот документов набралось пока 700 -800, ожидается до 2000 в обозримом будущем , но получилось в итоге что сразу все обработать не получается
то есть если не умеешь водить машину, то и не берись — ЭТО СЛОЖНО! АЙ-АЙ.
Люди ходят учиться машины водить, на права сдают. И, сразу после сдачи за вождение атомной подлодки не пытаются сесть.
или вас мама сразу «умным» и «всёзнающим» родила?!
Нет, не всезнающим. Многое пришлось самому осваивать, и это долгий процесс. Но и сейчас я не берусь за то, чего явно не знаю в большом объеме. Одно дело браться за то, чего чуть-чуть не знаешь, или можешь освоить в короткое время, другое дело браться за то, что без других явно не осилишь.
Мне не повезло, я нигде не учился программированию, до чего сам дошел, то и знаю,
Не надо плакаться. Мало кто учился. И я не учился. Еще раз: вопрос не в ваших знаниях, а в подходе к работе. Не беритесь за то, что явно не по зубам, и плакаться не придется на невезение. Все очень просто.
К чему — эта фраза вообще? не хотите по существу ответить — не надо, а учить как мне жить, за что браться, за что нет — не стоит я думаю ;)!
Вам, в силу недостатка опыта, не понятно на сколько сложная задача. Для вас она видимо просто сложная, то есть которую с подсказками можно решить. Я вам подсказываю, что это ваша большая и грубая ошибка. Я вас таким образом не научу программировать больше, но пытаюсь до вас донести, что надо более внимательно относиться к задачам и не хвататься за все подряд. Это тоже часть развития. Если вам такое развитие не нужно, то вряд ли вы станете хорошим программистом, потому что всего вы все равно не сможете знать и уметь (как и я не все знаю и умею), но будете лажать с непомерными задачами и по своей вине.
и опять не слова по существу вопроса :)!
Люди ходят учиться машины водить, на права сдают.
так я и учусь «водить», получаю ответы на не понятные вопросы, пробую, пытаюсь и делаю, кто сказал что такой метод изучения плохой.
Не надо плакаться.
Так я и не плакался, а заявил с гордостью!!! :)
Одно дело браться за то, чего чуть-чуть не знаешь, или можешь освоить в короткое время, другое дело браться за то, что без других явно не осилишь.
Забавно, а для меня непомерные цели всегда являлись только стимулом к их достижению, жалко что вы сдаетесь на начальном этапе и не стремитесь к непомерному :), наверно по этому пытаетесь давать плохие жизненные советы. :)
Sergey, я уже предлагал посмотреть на habrahabr.ru/post/253737/
с чем работать будет быстрее, удобней и правильней если все 22 ТВ перенести в MIGX ТВ 1 2000 документов с одним MIGX 2 Один документ с 2000 MIGX строками, где наши 22 значения
Как такой подход — попробовать и то, и другое, и сделать выводы. А заодно и с остальными поделиться. Здесь не академия, тут не учат. Тут люди делятся своими наработками. Если этого никто раньше не делал, то никто и не бросит свои дела, чтобы сделать всю работу за вас. И это не потому, что все тут такие плохие. Просто у других людей тоже есть свои задачи, которые за них никто не сделает. Я не могу понять, к чему эти комментарии про обиженную гордость. Это не дает ответа, а только отвлекает других (например, мне приходят сообщения о новой информации на этой странице, и я вместо чего-то дельного вижу очередную попытку доказать, что «я не такой»). Мой Вам совет — просто поищите информацию. Ее по тому же MIGX немало. Полного ответа не обещаю, но что-то, что поможет — точно есть. И НИКТО не будет заниматься этим за вас.
Все верно, почти со всем согласен, конечно не сижу и не жду решения от кого-то, естественно ищу его сам, перечитал кучу инфы и наверное уже нашел решение (не знаю, пробую сейчас как раз) я и не рассчитывал на нравоучительные разговоры ни с чьей стороны, был короткий вопрос, ожидал на него или короткого ответа: типа так лучше… Либо вообще без ответа —
Если этого никто раньше не делал
, то наверное и не знает никто
Это последнее отступление, больше писать что либо не по существу не буду, всем сори…

Добавить комментарий