Срочно! Как сделать чтоб и волки были сыты и овцы целы?

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

У вас тсоит сейчас внизу статистика выдачи страницы - главная полная генерация 0.2 секунды - это сверх много. Возьмите нормальный движок. У меня любую главную движки отдают не более чем за 0.001 секунды и это считается большой нагрузкой, а которые по слабее сайтики то отдают главную за 0.0001 и это уже нормально.

Поэтому:

1. Меняйте движок.

2. Смените хостера.

ИМХО.

И та и другая величина - бредова, по определнию. Просто из-за того, что она никак не связана с реальным временем. Таймеры выкого разрешения, основанные на модуле Time::HiRes, или подобном, работают в виртуальной среде, а не в реальной.

Их резульат верен, только в реальной среде.

В виртуаольных процессах, только время, с выборкой 1/17 секунды - является реальным.

А вот с этим полностью согласен.

С точки зрения технической реализации вам нужно искать хостера с наличием nginx и memcached - это решит проблемы с ботами и посетителями на 200%.

За примерами таких хостеров обращайтесь в личку.

Библиотек для использования memcached в PHP и Perl полно

T.R.O.N. - полностью согласен что в виртуальной среде. Но у человека на сайте такой же таймер кажет 0,2 и это сверхмного. Поэтому и говорю человеку, чтобы движок пересмотрел. Таймер должен показывать цифры такие или чуть большие, чем я написал выше.

А хостер - тут нет слов, если только конечно он не бесплатный (хотя и бесплатные есть с параметрами на много лучшими).

Это никак. Ибо величина, ничего не показывающая.

Во вы гоыорите 0.2 или 0.00001 - что это. Что это за время?????? от чего до чего?

- от начала до конца скрипта? В этом случа не учитывается время на начальную и конечную обрабутку самомго транслятора. Да и отправка клиенту - это отправка в буфер, а не клиенту.

- от начала до конца транзакции с клиентом? Еще больше вопросов??????

Отчасти так и было. Сейчас исправляется. База используется преимущественно для новостей. Кешировать их невижу смысла, так как обновляются каждую минуту. В остальном уже большая часть багов (выловленная) исправлена. Смотрю статистику трафика и выходит на 280 посетителей + боты - 290Мб трафика. В сравнении с прошлыми датами - значительное понижение (мин. в 3 раза). Движок написал сам, правда делал это от случая к случаю, поэтому ... В общем хостинг виртуальный. Время, которое он сейчас показывает от начала скрипта - до завершения, перед выдачей страницы достаточно условно на мой взгляд. Провайдер говорит, что виртуалка стоит на 4-х процессорном сервере. Но виртуальный хостинг, как я вижу из вышеперечисленных мнений, это не идеальное решение. Величина времени выдачи страницы, опять же на мой взгляд была бы быстрее, если бы я движок реализовал функциями, а не классами. У меня там 90% классами реализовано, мне так удобней незабывать, что к чему. Классы в PHP как известно, работают медленней. Но это удобней, или не так? К тому же прогрессс не стоит на месте.

T.R.O.N.

Это время на текущей машине от начала и до конца исполнения кода со всеми запросами, до отправки в буфер. И эта величина очень большая. Тут могут быть несколько вещей:

1. Алгоритм движка хромает, его нужно менять.

2. Машина слишком слаба, или перегружена из за неудачных настроек.

3. Хостер втиснул много клиентов на один сервер из жадности.

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

и я об этом. Значит никакого отношения к скорости исполнения - не имеет. Нужно смотреть, что за транслятор стоит, и сколько у него в АutoLoad стоит модулей и каких.

PS Я подобные вещи, стараюсь вовсе делать без явных БД. Это проще и быстрее работает.

PPS Сейчас пошла мода(на мой взгляд очень не оправданная), все переводить в UTF-8. А значит растет объем информации + падает скорость

Прихожу к выводу что имеет место во первых №3, потом №2. Протестировал движок на Core2 6400 главную выдаёт за 0,06с, на Celeron900 - 0,4 , на сервере - 0,15. Идея и реализация движка, изначально заложенная мной в работу сайта состоит в следующем: Полностью редактируемые шаблоны для любой страницы, включая отдельные элементы (шапки и т.д.); модульность - отдельный модуль для работы любого раздела сайта (по необходимости); универсальность работы - работа как on-line так и off-line с последующим полным контролем и загрузкой изменений одним сжатым файлом. Естественно все редакторы шаблонов и модулей имеют интуитивный интерфейс, позволяющий легко приспособиться в управлении сайтом потенциальному модератору, не имеющему представления о технологиях ну и т.п. В общем динамика по максимуму. Основа: Apache, PHP, mysql. Это конечно же, даже наверняка, уже давно и кем-то реализовано. Но я предпочитаю собственные грабли. На данный момент, если брать вёрстку страницы, я не вижу ничего лишнего, для работы идеи этого движка. Каждое подключение или файловая операция или запрос к БД оправдан (из расчёта на нагрузку как mysql-сервера, так и виртуалку), по крайней мере на данный момент с учётом запросов к серверу со стороны поисковиков и тематической аудитории.

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

P. S. за 14 дней августа только роботы яндекса потребили около 10 гиг. гугл - 1,5 гиг. meta.ua -1,2 гиг.

Все относительно в этом мире. Сервер выделенный? Какой проц? Винт сказевый? Памяти сколько? Сколько строк кода? Сколько запросов в базу? Мемкешед юзаете? Что на первой странице? Статика? От типа пользователя зависит рендеринг?

Допустим наш CMS движек на пнеD 2.8 сейчас отдает 20-40 страниц в секунду в зависимости от сложности страниц, но это никому ничего не скажет.

Анекдот в тему.

Летят Петька с Василием Иванычем в самолете:

- Петька, прибор?!

- Двести двадцать!

- Что - "двести двадцать"?

- А что - "прибор"?