Простейший случай. PHP выполняется в среде с chroot. А он очень часто именно так и выполняется.
И какая тебе польза будет от "серверных путей"?
И с какой стати 'DOCUMENT_ROOT' должен будет вообще совпадать с "серверными путями"?
И второй момент. Если используются симлинки, то ни __DIR__, ни __FILE__ в определенных ситуациях помочь не смогут.
Позиция проста - нафик нам такие законы. А методы у нас разные.
Позиция в корне не верная. Метафорически: Если тебе не нужен говнокод, то надо не выкидывать этот код, а увольнять говнокодера. Ибо вместо выкинутого говнокода, он накодит нового.
VestCoastman На Никиту Михалкова намекаешь? Точно, еще тот перецец. Наснимает муйни, а потом у него пираты виноваты, что это никто покупать не хочет.
Но я ему лично благодарна. Теперь качая фильмы с трекеров, я не чувствую себя преступницей, ибо я оплатила право это делать. А значит это уже не воровство и не преступление, а легальное получение контента.
Мелкий те как раз по существу и сказал.
Вот те простой пример. Буквально вчера разбирала код страницы. Чутка изменила логику, чутка подправила, и время выполнение скрипта изменилось с более 200мкс до менее 50мкс.
Вот банально основываясь на этом примере, уже можно сказать, что рукожопому программисту потребуется в 4 раза больше процессорной мощности, чем адекватному. Для решения одной и той же задачи.
Или более простыми словами, код написанный одним программистом, может легко выполнятся на 1м процессорном сервере, тогда как код написанный другим программистом, будет тормозить на сервере с 4мя такими же процами. Но обе программы будут решать одну и ту же задачу.
Винты. А точнее дисковая подсистема. Опять же упирается в задачу. И в ее реализацию. Иногда и одного зеленого винта достаточно, а иногда и 50райд из рапторов ложится напрочь. Опять же. Если нагрузка "пикообразная", то увеличение ОЗУ даст прирост больше, чем увеличение пропускной способности дисковой подсистемы. И опять же, нагрузка будет сильно зависеть от кривизны рук программиста.
Сколько каждый "проц может выдержать оперативы" легко находится в даташитах на процы. Теоретически 2^64 степени. Но столько ты ни в одну мать не натолкаешь, даже если грабанеш банк. И второй момент. Не каждая ОС увидит 2^64 ОЗУ.
ОС. Опять же от задач. Мне нравится BSD и RedHat. Но это дорогие решения.
А вообще, мне что-то подсказывает, что тебе абсолютно ничего не надо, а разговор ты тут завел, [вырезано]. Тебе же дали конкретную модель. Чем тебе она не устроила?
А те никто и не хамит. Я же не виновата, что ты ни только маны читать не умеешь, но, как оказалось еще и о поискавиках не знаешь, по этому читаешь всякую чушь.
Выборка почти никогда не попадет в кеш так как данные часто изменяются, по этой причине даже отключено кеширование данного MySQL запроса.
Мда? Вот потому, что ты такой бред пишешь, тебя и отправляют учить мат часть.
Прежде чем выборка будет произведена, сначала ОС загрузит все данные в дисковый кэшь, если их там нет. А запрошены с диска будут только те данные, которых нет в кэше самого сервера. Прежде всего, стоит помнить, что БД MySQL, это всего лишь обычный файл.
Если не путаю, то MySQL имеет собственные кеши для хранения данных, (а не только запросов!), а уж ОС будет кешировать их обязательно. По этому рациональнее отдать память под ДИНАМИЧЕСКОЕ хранилище, которыми по факту и являются кеши. Очень редкие задачи требуют RAM дисков, и твоя, не из их числа. Кста, память занимаемая RAM диском в своп не вытесняется. Если писатель не рукожоп конечно, или специально не предусмотрел такой возможности.
PlayTime пишет:
Но если таблица была изменена то данные уже не будут браться с кеша а опять сделают выборку с диска.
Да нифига подобного. Данные останутся в КЭШе, читай в памяти, и только в случае длительного простая, и при условии нехватки памяти другим задачам, твои данные будут удалены из кэша физически.
И еще одно. Если данные попали в своп, это еще не означает, что они физически удалены их памяти. Данные могу находится одновременно и в свопе на диске, и кеше. И только при нехватке ресурсов они будут удалены из ОЗУ физически.
PlayTime пишет:
Я не гуру в администрировании и не знал что "хорошие" сервера своп не используют
Гуру об этом то же не знают, так что не переживай.
LIME Какой те пруф если ты банальных вещей не знаешь. Набери в гугле "линкус для чайников" он те сотни пруфов даст. Короче, хорош тупить, и топай в гугль. Раз знаний не хватает, что бы в мане что-то найти.
RedHat. Проблем нет.
Первая же ссылка из гугля: http://www[dot]falsecode[dot]ru/blog/?p=196 Там то же проблему решили.
Я же говорила, читайте маны. А не надписи на заборах.
Зря, ты расценил это "криком негодования". Это была простая констатация фактов.
Доказательства, можете получить сами и довольно легко. Было бы желание.
А так как у меня только переписка по E-MAILу, которую элементарно подделать, то у меня лично, получается доказательств нет. Если по поводу невозможности блочить по УРЛ, то информация по РосТелеКаке была в прессе, в том числе и в печатном издании. По ХренЛайну есть пост сотрудника этой компании на харбаре (как он там правильно пишется то?).
То есть вся информация, которую я предоставила, легко берется из ОТКРЫТЫХ, и пока не забаненых источников. Остальное добывается за несколько минут. А вылезать на чужом горбу, это без меня. Мне откровенно начхать, что там в рашке банится, и почему. Как показали последние выборы, более 2/3 населения страны все устраивает.
Мне было интересно проверить, как это на деле работает, я проверила, результатами поделилась. И не более того. Того и вам желаю.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 147
источников. Остальное добывается за несколько минут. А вылезать на чужом горбу, это без меня. Мне откровенно начхать, что там в рашке банится, и почему. Как показали последние выборы, более 2/3 населения страны все устраивает.
