С флешем баги однозначно.
Есть проект свой на flex, с рендерингом автоматическим — перерисовка при каждом движении мышки — во всех браузерах летает, в Chrome — виснет не по детски.
А хотя бы сейчас — можно поинтересоваться кол-вом генерируемых страниц или даже скорее — обработываемых запросов в сутки — при пиковых нагрузках и среднестатистических )))
что быстрее — обойти 72млн страниц за 55 дней (включая обработку на лету)
или же на машине втрое слабее вашей, за 500руб в месяц — обойти 72млн страниц за 3 суток и потом их обсчитать?
со своим уставом в чужой монастырь не лезут конечно, но разница более чем в 10 раз — стоит призадуматься… к тому же — меньше времени на сбор-обработку больше времени на эксперименты ;)
я бы посоветовал подумать над алгоритмом, уж больно затратный у вас.
я с рунета начинал обходить. сначала рунет за 3 дня, потом за сутки, потом за 6 часов))
теперь на хилом серваке можно еще меньше потратить… главное чтобы места хватило))
как подсказка — зря так много бд спрашиваете, можно практически без запросов к бд сделать.
а бд использовать только для обработки конечных показателей.
(и не файловая, просто немного подумать — как именно в очередь ставить в многопоток, с точками останов одновременно — чтобы остановить-продолжить можно было… ;) )
трафика сжирает много но и провайдеров с безлимитками достаточно.
ресурсы нужны не такие уж и большие))
именно для сбора — главное оперативная память, процессор и более главно — широта канала.
имея опыт подобных проделок, могу сказать, что
имея машинку 500Мгц, 128мб рамы + 100mb/s порт — можно сохранять странички со скоростью 15к/минуту
при стабильной нагрузке, оставляя немного ресурсов для работы с сервером.
и ~20к/минуту если серв не жалко(в это время ответ от сервера достаточно долггий идет, максимум ssh).
15к у меня выливалось примерно в 60-80 потоков, 20к в 80-120 потоков
так, что представьте что можно сделать — имея например машинку 3гц CoreDuo/ 2Gb рамы/ 1Gb/s порт — на которой можно запускать для стабильности ~1000 потоков, которые к тому же будут работать быстрее — ибо 1gb порт — не халабала))
Не вижу противоречий в Ваших комментах и моём топе =)
Логику никто не отменял, и я вроде не предлагал использовать повсеместно ;)
Собственно статья вовсе не рассказывает где и как именно применяются Getter/Setter в программировании,
она лишь показывает достаточно красивое и эффективное решение данного вопроса не более, и ни в коей мере не является панацей от всего =)
Например, мне в силу особенностей некоторых моих реализаций — более чем необходим был инструментарий с которым я мог бы совершать прямые присваивания $this->myProp=$value;
и при этом пользоваться функциональностью Getter/Setter и более того, мне крайне необходимо было избежать случайных присваиваний =)
А про быстродействия — то, что кешируется — выводится «моментально» — а! микросекундные! задержки при совершении административных операций — мне кажется обсуждать нет смысла ;)
«...-преждевременная оптимизация — корень всех зол-...»
именно =)
разница достаточно копеечная (учитывая что 10к присваиваний врятли будет в рамках одного вызова)
а быстродействие — как бы ни старался, на серьезных проектах без кеширования не обойтись.
а там где есть мудрое кеширование — вопрос с подобным быстродействием впринципе гораздо менее актуален, чем предельная прозрачность, удобство архитектуры и скорость правки, расширения =))
в Вашей интерпретации метод getHeight и не должен вызываться, поскольку к свойству height Вы обращаетесь внутри класса.
В данном случае height находится в области видимости класса MyRectangle — и следовательно magic метод __get не вызывается.
если вы попробуете вызвать снаружи —
class MyRectangle extends Rectangle{
}
$mr = new MyRectangle();
echo $mr->height;
метод getHeight — сработает.
Так что — работает так как и должно))
читаю не первую вашу статью, и кхм… дочитав очередную чувствую себя одной из тех кошек =))
А вобще молодец.
Есть проект свой на flex, с рендерингом автоматическим — перерисовка при каждом движении мышки — во всех браузерах летает, в Chrome — виснет не по детски.
циферки — оченя люблю, соревновательный дух поддерживает — люблю посоревноваться )))
зы. гугл — к соревнованию не предлагать, я до него попозжя дойду, пока времени на него нет ))
Наглядности тобишь конечной не хватает))
тогда другой вопрос —
что быстрее — обойти 72млн страниц за 55 дней (включая обработку на лету)
или же на машине втрое слабее вашей, за 500руб в месяц — обойти 72млн страниц за 3 суток и потом их обсчитать?
со своим уставом в чужой монастырь не лезут конечно, но разница более чем в 10 раз — стоит призадуматься… к тому же — меньше времени на сбор-обработку больше времени на эксперименты ;)
минимум 100мб. и разделяйте сбор & обработку данных
я бы посоветовал подумать над алгоритмом, уж больно затратный у вас.
я с рунета начинал обходить. сначала рунет за 3 дня, потом за сутки, потом за 6 часов))
теперь на хилом серваке можно еще меньше потратить… главное чтобы места хватило))
как подсказка — зря так много бд спрашиваете, можно практически без запросов к бд сделать.
а бд использовать только для обработки конечных показателей.
(и не файловая, просто немного подумать — как именно в очередь ставить в многопоток, с точками останов одновременно — чтобы остановить-продолжить можно было… ;) )
ресурсы нужны не такие уж и большие))
именно для сбора — главное оперативная память, процессор и более главно — широта канала.
имея опыт подобных проделок, могу сказать, что
имея машинку 500Мгц, 128мб рамы + 100mb/s порт — можно сохранять странички со скоростью 15к/минуту
при стабильной нагрузке, оставляя немного ресурсов для работы с сервером.
и ~20к/минуту если серв не жалко(в это время ответ от сервера достаточно долггий идет, максимум ssh).
15к у меня выливалось примерно в 60-80 потоков, 20к в 80-120 потоков
так, что представьте что можно сделать — имея например машинку 3гц CoreDuo/ 2Gb рамы/ 1Gb/s порт — на которой можно запускать для стабильности ~1000 потоков, которые к тому же будут работать быстрее — ибо 1gb порт — не халабала))
зы. у самого есть слабость к подобным вещам, практикую бывает. оттуда и интерес ;)
Логику никто не отменял, и я вроде не предлагал использовать повсеместно ;)
Собственно статья вовсе не рассказывает где и как именно применяются Getter/Setter в программировании,
она лишь показывает достаточно красивое и эффективное решение данного вопроса не более, и ни в коей мере не является панацей от всего =)
Например, мне в силу особенностей некоторых моих реализаций — более чем необходим был инструментарий с которым я мог бы совершать прямые присваивания $this->myProp=$value;
и при этом пользоваться функциональностью Getter/Setter и более того, мне крайне необходимо было избежать случайных присваиваний =)
А про быстродействия — то, что кешируется — выводится «моментально» — а! микросекундные! задержки при совершении административных операций — мне кажется обсуждать нет смысла ;)
именно =)
разница достаточно копеечная (учитывая что 10к присваиваний врятли будет в рамках одного вызова)
а быстродействие — как бы ни старался, на серьезных проектах без кеширования не обойтись.
а там где есть мудрое кеширование — вопрос с подобным быстродействием впринципе гораздо менее актуален, чем предельная прозрачность, удобство архитектуры и скорость правки, расширения =))
Можно и нужно производить =)
В данном случае height находится в области видимости класса MyRectangle — и следовательно magic метод __get не вызывается.
если вы попробуете вызвать снаружи —
class MyRectangle extends Rectangle{ } $mr = new MyRectangle(); echo $mr->height;метод getHeight — сработает.
Так что — работает так как и должно))