FixGuitar

FixGuitar
Рейтинг
17
Регистрация
26.11.2006

Код текущего дизайна правиться в файлах текущей установленной темы оформления.

Для поиска нужного файла (напр. здесь "forum/Themes/default/") воспользуйтесь функцией поиска по тексту (прямо по всем файлам). В качестве критерия для поиска - файлы .рнр, в качестве текста - текущий кусок кода шапки. Работает 100%.

Ну если нужно оно кому будет, сделать такой скрипт не проблема.

Вот только будет ли пользоваться спросом он..

Читал читал этот тред.. и почему народ начал уходить от темы всё больше и больше с каждым сообщением.

Понял, что совершил тут такие ошибки.

1. Разместил не в том разделе тему

2. Забыл упомянуть очень важную вещь в своём первом сообщении. :)

Я статью пишу в помощь хостерам виртуального хостинга. Для того, чтобы админы не писали одно и тоже в своих форумах по поводу многочисленных вопросов на подобную тему, а предлагали к прочтению такую статью.

Всё мною перечисленное относилось только к виртуальному хостингу.

То-то и смотрю, что говорим мы на "немного разных языках" :) Я придерживался одной концепции, Вы другой, поэтому и получился такой "разнообразный" :) разговор.

T.R.O.N:
а это - больше напоминает набор мыслей из учебника информатики для начальной школы.

:)

1. Много ли школ сейчас изучают MySQL, PostregreSQL, PHP, Perl, CGI?

Очень хотелось бы, чтобы в моих учебниках по информатике были бы хотя бы какие-то упоминания об этом. Здесь Вы явно загнули.

2. Ваш набор мыслей интереснее в случае не виртуального хостинга. В условиях виртуально это всё "сложно применимо", если вообще возможно.

Но это моя невнимательность.

Зато получился отличный обзор по поводу нахождения узких мест на серваках :) Который несомненно поможет администрированию серверов начинающим пользователей.

Тема получилась очень даже информативная.

Слава Шевцов,

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

=offtop=

Gray:
Он не будет смеяться, он программист.

За чтож так программистов не уважаете?

И к словам цепляться не надо, их не для того говорят :)

=/offtop=

Gray:
Поэтому для него есть только один способ - сесть и начать переписывать код.

Абсолютно неуместный стёб.

А такие скромные меры, позволяющие учетверить переносимую нагрузку, как оптимизация размеров буферов mySQL, включение Query Cache, установка разумных Expires для статических элементов страниц и так далее

Всё верно, это один из путей снижения нагрузки. Но как говориться, одно другому не мешает.

Наша тема о том какие варианты снижения нагрузки существуют/доступны, а какие из них выбрать это уже дело владельца сайта.

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

Но за Ваш вариант, спасибо, он весьма актуальный.

Спасибо за советы!

Gray:
Ерунда какая-то, а не советы.

Это был всего лишь небольшой старт-ап :)

Gray:
Ага. Берете, значит, проект с мегабайтом кода и давай оптимизировать скрипты.
Не забудьте еще про мир во всем мире написать - столь же реально.

Ну а куда же деваться. При мегабайтах кода, возможно, проще переписать некоторые "грузные" участки/скрипты, чем переписать с нуля, как Вы предлагаете в своём сообщении.

По переводу баз данных в тхт на MySQL - парсинг больших файлов занимает много времени и даёт большую нагрузку.

"большие тхт", насколько большие?

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

Понятное дело, что конечном счёте MySQL это тоже файлы, но я сейчас не об этом. MySQL это специализированный сервер баз данных, если его оптимизировать корректно (верно устанавливать основные/др. ключи, проводить индексацию), то здесь несомненно будет выигрыш в скорости и производительности, нежели у обычных текстовых файлов, в которых этого всего вообще нету.

Если база данных находится в "простом" (отсутствие спец. структуры, напр.) формате текстового файла - лучше перевести её на MySQL.

Если писать спец. формат базы данных, то это уже другой, весьма не простой вопрос. И не отрицаю, что вполне приемлемый. Единственное не стоит забывать о том, что над MySQL тоже не дураки работают. Это годами отработанное средство хранения баз данных. Не так-то просто написать что-то лучше. Тем более малой группой разработчиков :)

Gray:
А все эти "советы" можно заменить одним - выбросьте старый код и напишите новый заново. Идеальная установка для программиста-двоечника.

Ну зачем же сразу выбрасывать его. Возможно целесообразно переписать только некоторые участки/скрипты, а не весь проект.

Хотя возможно Вы сейчас говорите как раз о частях, а не о всём коде. Тогда прошу прощения.

Kpd,

Я-то программист :) Но статью пишу не только для программистов, а в качестве обзора для владельцев проектов - откуда могут исходить подобные нагрузки. Вовсе не обязательно, что её читать будут и интересна она будет только программистам.

По поводу Вашего сообщения. "сразу нормальные скрипты" слишком обширное и сложное понятие. :)

Нередко цели скрипта меняются, ещё что-то, всякие ситуации бывают.

Изначально идеальный или "нормальный" скрипт никогда не напишешь. Всегда можно что-то улучшить по ходу процесса создания скрипта. Всегда. Код постоянно улучшается. Рефакторинг спасёт человечество :)

Velior,

Спасибо. Мысль интересная.

Слава Шевцов,

Спасибо большое. Идею кэширования запросов я действительно упустил.

Miracle,

Полностью согласен. Не прочёл изначально Ваше сообщение, поэтому чуть выше написал почти всё тоже самое про улучшение скриптов :)

Спасибо большое за участие в теме. Надеюсь она хотя бы кому-то поможет, тут собрана действительно полезная информация!

Хочу сказать спасибо всем купившим этот скрипт! Премного Вам благодарен за Ваш выбор!

Значит затрачиваю усилия я всё-таки не зря! ;-)

Спасибо!!

Я смотрю, что отзывов тут никаких о скрипте не оставляют, а покупки, тем временем, идут. Может палиться просто не хотят, может ещё чего.. :) Если не сложно, отписывайтесь хотя бы в личку, чтобы я знал, что Вас устраивает, что не устраивает, что успешно реализовано, чего не следовало всё-таки делать.. Так я хотя бы примерно буду определять курс своей дальнейшей работы.

хм.. правда идут покупки может быть и не с этого форума :) :)

Из небольших нововведений в администрировании - вместо ссылки на функцию:

"Разослать статью всем копиям каталогов"

Теперь там ниспадающий список, где можно выбрать рассылку статьи как по всем копиям так и в частном порядке любому каталогу.

Классная функциональность получается, аж самому понравилось. Если не хочешь разбрасывать статью по всем - можно любому, которому нужно. Ну прям полный контроль :)

Вообще думал сделать кучу checkbox'ов, но когда каталогов под 100-300 (и больше) это смотриться не очень красиво, поэтому здесь я ещё мозгую в каком виде это лучше представить.. Может подскажете?

Чего такого эдакого прикрутить в скрипт? :)

Готово! В качестве описания новых возможностей скрипта, приведу выдержку из своего блога. Вот собственно, что мы имеем на данный момент:

Получилось даже ещё интереснее, чем я ожидал! Многие (полезные!) функции получились "сами по себе", не думал даже их делать, но по ходу программинга подумал, "чёрт, а почему бы и нет!?", таким образом и ввёл кучу (повторюсь, полезных!) функций, которые всё-таки хотел оставить за бортом.

Всё для Вас!

Из основных нововведений теперь стало можно управлять всеми копиями каталогов из одной.

- добавлен модуль DControl для централизированного управления всеми каталогами;

- переход на любой каталог из одного с автоматическим залогиниванием в другом;

(круто сказал, аж сам не понял смысла)

- рассылка указанной статьи по всем каталогам;

- централизированное модерирование статей всех каталогов из одной копии;

- ещё некоторые особенности увеличивающие производительность и скорость работы скрипта...

не стоим на месте, в общем! :-)

Шаблоны свободно меняются (обычные HTML, CSS файлы), лёгкая установка (автоматический инсталлятор), низкая нагрузка на сервера, заточка под сео, подстраиваемость под сетки сайтов, неограниченное количество категорий и подкатегорий, которые позволяют делать как узкотематические, так и не очень каталоги - о чём ещё можно мечтать?

Тут я выступаю как разработчик скрипта, а не как посредник, поэтому и проконсультировать смогу (БЕСПЛАТНО!) по поводу установки, настройки, эксплуатации скрипта.

Если будут найдены в скрипте какие-то критические уязвимости/"нерабочести" - предоставлю бесплатные апдейты. Это всё без проблем - я уже давно практикую такое со своими клиентами. За свой код я ответственен и отношусь к этому весьма серьёзно.

По цене VXDCat 1.1 подорожал на 10 баксов. И терь стоит $40. (оплата возможна по WM или Yandex.Деньги).

Разработки на этом не прекращаются. Куча идей в голове, которые все хотелось бы воплотить в код. Ну и Вы предлагайте какие-то свои идеи. Рассмотрю все варианты!

А все мои предложения, собсно, остаются в силе.

Ну и вот собсно демка.

VXDCat 1.1 в действии!

(входные данные в админку: admin/111)

Чтобы продемонстрировать работу централизированного модуля управления всеми копиями, запустил ещё два независимых друг от друга каталога:

http://best-projects.net/vxdone/

http://best-projects.net/vxdtwo/

Ими собсно и управляем.

Ай хоп ю инжой ит! :-)

А какие именно функции Вы хотите видеть в модуле "удалённого контроля за несколькими каталогами"?

Модерирование статей, рассылка их по остальным..?

Управления с одной админки пока что нету.

Честно говоря, не думал, что так остро встанет эта проблема. :) Займусь в ближайшее время.

Зарегил. Абсолютно без проблем. Быстро среагировали. Спасибо!

123
Всего: 29