Да, мужики, фигню какую-то я предложил. Возможно, что проект не с нуля разрабатываю и просто поверил, что так можно, не видя альтернативы =\ Делаешь на клиенте проверку на возможность/невозможность действия, а потом на клиенте проверяешь все приходящие данные.
Да что Вы говорите? Может будете всё-таки уточнять что потянет? А то, такие советчики на форумах говорят, что всё будет круто, а потом наши клиенты удивляются, чё мы их с shared хостинга гоним, когда они половину квад ксеона жрать начинают...
10к уников это ерунда, если они по 2 страницы на рыло загружают а вот если по 100... так что тут не униками мерять надо
И не такие кадры бывают. У нас один хотел на shared Битрикс с 20к уников повесить. При этом настоятельно утверждал, что у нашего конкурента успешно размещался именно на шареде... Любая более менее функциональная CMS уже на 3-5 тысячах уников вылазит за рамки shared-хостинга.
Noobie ну я говорил про быдлокод, быдлосерв в мой круг обзора не входил =) тут как говорится, выбери одно в ущерб другому
Именно поэтому сайт эльдорадо - высоконагруженый проект 150k хитов/сутки это хайлоад для одной машины, но не для кластера.
А 1500k в сутки - это хайлоад для кластера, но не для стойки серверов. А 15m в сутки - это хайлоад для стойки, но не для датацентра с серверами. И что? Высокагруженный проект - это не тот проект, который нагружает доступный процессор на 99%. А то, знаете ли, я подниму сайт на Z80 и десяток человек сделают его высоконагруженным.
В том то и дело, что именно тот. И оптимизация призвана эту нагрузку снизить. Нет смысла оптимизировать систему, которая и так работает нормально - пусть это будет прожерливая cms'ка на крутом железе. Хайлоадом проект может считаться, когда его приходится оптимизировать для экономии системных ресурсов. Для каждого проекта существует грань, с одной стороны которой дешевле купить железо, с другой - оптимизировать код.
Вопрос задач. Сервак не ложится, а ресурс выходит за рамки услуги. Shared хостинг - это услуга, в которой гарантированный ресурс только жёсткий диск. Оператива и проц туда не входят. И если появляется на сервере из двух тысяч клиентов один, который жрёт даже одну десятую сервера, его уже надо от туда гнать. Или услуга себя окупать не будет, когда оставшиеся 1999 начнут ныть, что у них всё медленно работает. Я работаю в сфере хостинга с 2007 года, поверьте, знаю о чём говорю...
[vs] - значит, если я начну оптимизировать код для Z80, что бы он выдержал не 10 человек, а 12 - то прокт становится хайлоадом? Успокойтесь, нет никакого четкого определения хайлоад или нет, а вернее - у каждого свое такое определение, и то весьма размытое.
Не спорю. Я согласен с md5 что хайлоады не делаются на прожерливых движках, тем более на движках с закрытым кодом - попробуйте его оптимизировтаь.
У битрикса не закрытый код =) И прожорливость движка - это некая страшилка для детей - любят поминать, но никто не может толком объяснить в чем суть этой прожорливости.
MiksIr Битрикс - самая прожорливая CMS на сегодняшний день. Поверьте [vs] Какая оптимизация кода? Я вас умоляю... Половина клиентов даже nginx + eccelerator поставить не могут
Да хотя бы кэширование. Популярные движки в целях унифицикации ничего не кэшируют в памяти. Некоторые вообще делают много лишних запросов (где-то на форуме было про 20 с лишним запросов к БД для генерации главной страницы блога на wordpress). Многофункциональность в принципе подразумевает лишние затраты ресурсов. В том же битриксе магазин - модуль. Модуль - это абстракция, а чем выше уровень абстракции (функция, объект, модуль, модель), тем больше затраты. Универсальный - значит, прожерливый.
В битриксе есть один из уровней кеширования. Т.е. по вашему для хайлоада годится только плоский говнокод, а всякие ООП-ы - это для бездельников, которые свои домашние страницы делают? Пишите еще Ж)
на assm (уже обсуждалось) Виртуальный сервер P300. Генерация страницы от 2 до 4-ёх секунд. О проекте: около 300 файлов, шаблоны xml (парсим на лету) Выполняю сведение все в один файл (получилось конечно 5 файлов: один большой и четыре малюсенькие) Результат: генерация страницы 1.5 - 3 сек Включаю в ход профайлер, убиваю половину ненужного функционала (самыми прожорливыми оказались is_int, is_null, is_numeric, method_exists, assert, is_readable). 100% гарантии не даю, но на первый взгляд все работает. Компилирую шаблоны. Результат: генерация страницы 1 - 2 сек (практически в два раза по сравнению с оригиналом) Устанавливаю APC: Результат оригинала: 1 - 2 сек Результат оптимизированного кода: 0.6 - 0.8 сек Перевожу все на P1200 Результат оригинала: 0.5 - 0.8 Результат оптимизированного кода: 0.4 - 0.6 Оставил все в оригинале (т.е. 300 файлов с кучей assert'ов, к месту и не месту, не откомпилированы шаблоны ), т.к. 0.1 - 0.2 сек на данный момент не критичны, а париться с кодом в 20 тыс. строк в одном файле не больно хочется