я думаю, к ТС прицепились не из-за скана контента, а из-за того, что он упирает на то, что контент отрерайчен РУКАМИ и с умом...
но позвольте спросить, в каком учебном заведении учился человек, который руками напишет следующую фразу:
это же бред полнейший! мне кажется ТС "хочет, казалось, больше получить намного, чем затрат сумма ее"...
☝ о! я понял! это записано со слов МАСТЕРА ЙОДЫ!!! ТС взял его в заложники и заставляет читать тексты в программу распознования речи!!!!!!!
и предположительный кусок оригинала с http://www.carpedia.ru/page/34/
Как первый среднемоторный спортивный автомобиль Audi R8 соединяет опыт Ауди, полученный от многочисленных побед в автоспорте с инновационными проектами и технологиями.
работа рерайтера заключалась в прогоне через прогу и сохранении результатов на диск... тут действительно нужны руки и голова (чтобы мышку кликать и думать, куда все это сохранить)
Decoy
Professional rewrAIter
no comments...
можно ввести поле под условным названем "счетчик" в которм будет хранится число дней до искомого значения.
при создании события выбирается тип: раз в N дней, каждый день недели, каждое NN число месяца и т.д. (сколько придумаете). в момент создания события, в зависимости от типа, рассчитывается число дней до очередного события и пишется в счетчик события
на крон вешате скрипт который будет пробегать по событиям и уменьшать "счетчик" на 1 каждый день
соответственно при выборке событий которые должны произойти сегодня - выбираем записи у которых счетчик=0
2ой скрипт на кроне должен запускаться после первого и перерасчитывать счтечики у записей, у которых счетчик стал равен "-1", т.е. прошел очередной день события и нало рассчитать кол-во дней до очередного по алгоритму "в момент создания".
как то так можно :)
возможно при "глючном" зуме идут очень большие расчеты, которые на локалке проходят, а сервак просто завершает скрипт по таймауту... попробуйте:
1. если есть доступ - увеличить память для скрипта + время таймаута (не 15 сек., а 60 например)
2. сталкивался с этим сам - обрабатывал картинку на основе созданной из Png - по ходу дела этот формат кушает памяти немерянно. на локалке ок, на сервере - не успевал отработать скрипт. решение - п.1
3. ну и радикальное - изменить поход к генерации картинок. т.е. написать скрипт, который сгенерит все варианты картинок для всех зумов и выдавать их уже пользователю в готовом виде в зависимости от координат и зума.
объясню про нагрузку...
все что можно в статику перевел, но некоторые моменты сайта просто не могут обойтись без подключения к mysql. Все работает быстро и прекрасно, пока с рамблера (сайт - новостник, рама иногда цепляет новость и ставит в топ новостей) не ничинают вагонами переходить пользователи... вот тут то mysql и падает :(
вот и стоит вопрос покупки машины, которая бы держала такаую нагрузку (хотя возможно mysql5 лучше в этом плане. сейчас 3.23 стоит)
я сделал похоже - высоконагруженные куски кода внутри страниц кешируются в отдельные файлы.
т.е. например на главной блок новостей кешируется в один файл, а блок анонсов в другой.
при этом можно настроить для каждого блока свое время обновления (например кеш блока новостей переписывается раз в 10 минут, а блок анонсов - раз в час).
при этом можно разбить кеш по другому: например закешировать header и footer в отдельные файлы (всего 2 файла будет), а контент страниц в отельные свои файлы и собирать их при генерации страницы. И, например, если в шапке что то изменили - просто удаляем cache/header.html, либо он сам перепишется через какое то время (если изменения не критичны).
ок. спасибо. примерно ясно на что ориентироваться.
бабла конечно не жалко, но надо как то обосновывать, кризис и все такое :)
хотелось знать от чего отталкиваться при выборе параметров.
нет, нужен физический сервер, который в компании и будет стоять
идеальный вариант. сам уже 1.5 года так храню пассворды после аналогичного случая...
