"Линкаторы": вопрос знающим технологию и организаторам

Вопросы туманные... Можно написать так, что хватит и P166mmx/256Mb.

На счет стабильности, видел я как-то на линкаторном сайте ошибку подключения к главному сайту :) Что-то вроде "не могу соединиться с linkator.ru" на пустой странице. Эти горе-умельцы не знают что такое кэш.

Если очень грубо прикидывать - сервак с 1ГБ памяти потребуется. Если не париться особо с оптимизацией производительности.

Сравнивать уместнее всего с баннерокрутилкой. И объемы примерно так же прогнозировать и жор ресурсов. И заказывать программинг кстати лучше наверно у людей, имеющих опыт в этой области.

Кеш со стороны клиентов затрудняет установку (как и вообще любая логика на стороне клиентов). Хотя и помогает в плане стабильности на случай отказа центрального сервера.

xyz, вот тебе простой совет, применив который, можно всё обустроить даже на сервере 485 DX 4-100 c 16 метрами оперативки, при тысячах получателей:

Делай раз - пусть твой PHP код получив документ кэширует его на сайте-получателе (сохраняет и пока время Ч не истекло более к твоему серверу не обращается), причём время Ч вычисляй сразу после загрузки так (если на сутки кэшируем): Ч_в_часах=36*RND(0.5)+12

Причём здесь RND?

-- Это позволит равномерно распределить нагрузку на сервер-донор.

Что это ещё даёт полезного?

-- Если сервер твой упал, то на сайтах получателях это не заметно, т.к. при невозможности получить новый контент они используют данные из кеша, а следующий запрос произведут через время Ч (или не Ч - решать вам).

absolut, скорее всего те ребята слышали что такое кэш, но видимо, они к этому ещё не готовы :)

Сравнивать подобные вещи вообще нереально. Все зависит от кривости рук программиста. Разница в ресурсоемкости скриптов может отличаться очень круто. Т.е. в зависимости от степени оптимизации время на обработку может раста как в виде N*ln(N), а может запросто быть и N^2 или N^3. И не посмотрев, что до этого писал программист и как оно работает, практически невозможно даже близко прикинуть сколько потребуется ресурсов.

Решение с кэшем на самом деле не такое уж и простое. С точки зрения снимания ресурсоемкости с сервера - да, но с точки зрения усложнения клиента, и главное его безопасности, начинаются большие вопросы. Плюс еще и на сервере требуется кучу всего дописывать, иначе можно получить еще как минимум один вид неприятных последствий.

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

Да смотря как писать... Я б на центральном сервере вообще статику генерил. И раздавал каким то легким веб-сервером. Нагрузка к нулю будет стремится

Newm, если не затруднит, подскажите:

+ какие именно грабли с безопастностью в варианте с кешированием?

+ что не так, в том простейшем варианте, с временем кеширования?

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

Направление мысли такое - правильному клиентскому скрипту не должно быть доступно ничего на запись на сервере клиента. Иначе в сочетании с разрешенными внешними сокетами - получается конструкция весьма стремная, особенно с точки зрения админа-параноика.

Vladimir_Rublin

Варианты возможны всякие, по мелочи, но до хрена. С учетом того, что скрипту дается право писать, что-то, то там сразу появляются проблемы. Доступ к клиентскому скрипту имеет любой, поэтому увидеть внутренности можно без проблем. Если уж PHPBB регулярно вскрывают (а сколько он уже в разработке), то с самопальным клиентом надо быть очень осторожным.

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

Затрахаешься писать проверку, ту ли информацию выдает клиент, что необходимо. А с тем количеством "умников", что у нас есть, без проверки никак нельзя.

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