Алексей Fr: это так не делается. Я тебе написал про сущность "группа контроллеров". К примеру у тебя есть главный контроллер, к примеру это новость. Когда пользователь открывает новость то ты рендеришь главный контроллер, но для того чтобы отреднерить дополнительные (хедер, футер, левую менюшку или какойнить баннер) то у тебя может быть механизм чтобы к главному конроллеру можно было прицепить пару дочерних и при вызове функции рендера главного контроллера рендерились и дочерние. таким образом ты можешь получить всю html разом
aka_starburry: немного не так. Когда вы соединяетесь с сервером на 80(внешнем) и 27000(внутреннем) порту то WP генерирует html со ссылками на css\js с указанием порта который php получил, а получил он внутренний порт(27000) и отдает это добро в браузер, браузер же в свою очередь начинает долбиться на 27000 внешний порт и получает шыш.
Алексей Тен: конечно много. осталось это сделать такой парсер как c++ модуль к node js и тогда даже скорость не сильно просядет. а если писать на js такой, то тут великие сомнения у меня насчет этой затеи.
Вадим Егоров: если углубляться настолько то у меня нет времени над этим думать) тут можно ловить время отправки и приема tcp пакетов а это уже больше похоже на бред
Вадим Егоров: долго думал щас над этой проблемой и дошел вот до какого вывода: все бессмысленно и жизнь тлен. То о чем вы говорите это поправка на временную зону. А изначальная задача - похоже что не решаема (мне так показалось). Проблема в том что одним запросом к серверу мы не можем выяснить время отправки запроса и приема ответа (как две отдельные величины). Из двух запросов мы это можем сделать но тогда проблема становится в неоднородности сети (это касается gprs или edge и иже с ними), первый запрос мог прийти быстрее а второй медленнее или наоборот и тогда мы не сможем скоррелировать эти два запроса и выяснить точное время. И если мы не можем положиться на два запроса то на более чем два и рассчитывать не приходится. Получается оптимальный вариант это один запрос. А из одного запроса мы можем знать только его общее время выполнения и тут приходится идти на жесткие уступки и делать предположения что время туда и обратно было одинаковым(что конечно же не так но другого не остается, пути одинаковы а время исполнения скрипта можно нивелировать потому что оно намного меньше чем время передачи) и тогда нужно получить серверное время плюс половина от того времени что ушло на запрос. Вот такая печаль несовершенного мира.
Вадим Егоров: кстати время отправки и приема могут впринципе отличаться. так что лучше по умолчанию делать несколько синхронизаций чтобы это выяснить, и, если это стабильно, на основе этих данных можно делать рассчеты
Вадим Егоров: тогда можно сложнее все навернуть. зафиксировать время в браузере, сразу же отправить его на сервер. Сервер в ответ отправляет назад то же время что отправил браузер и время которое на сервере. Таким образом можно получить задержки в отправке и получении. Если эти цифры значительно отличаются то делать ресинхронизацию (значительные различия во времени отправки и получении возможны когда прием сигнала не стабилен). Вообще это лучше делать раза два-три для того чтобы в этом убедиться наверняка. После того как в этом убедишься то у тебя будут на руках время сервернои и браузерное, останется лишь подсчитать серверное отталкиваясь от браузерного времени и тех данных что получил при синхронизации.
iborisbelov: ломать MVC незачем. акции у тебя лежат по ссылке index.php?route=product/category&path=255 по ссылке видно что у тебя акции это товар ибо ведут они на route=proudct/proudct. карусель что ты нашел это скорее всего модуль который ничем не поможет. рекомендую просто акции создавать категориями и прикреплять к другим категориям. в категориях делать превью в виде картинки и все. но насколько я знаю стандартного механизма ОП такого нету, так что надо кодить
причиной тормозов сайта может быть хоть вспышки на солнце. Профилирование через xdebug даст ответ на следующие вопросы: тормозит ли именно база?(я конечно понимаю что ты утверждаешь что это база, но к базе ты обращаешься через какой-нибудь phpmyadmin который в свою очередь тоже через php работает, не утверждаю что так но это стоит исключить в первую очередь), далее, если убедились что это именно база то идем в профилирование sql запросов и смотрим на что время тратится (на старт, на проверку прав, инициализацию или оптимизацию запроса или гдето в сети застревает). Имея эти данные на руках уже можно делать более обоснованные выводы, нежели "у меня все не работает, а вы мне не можете помочь". Вдруг это вообще апач какойнибудь? Вы уверены что это не апач?(щючю)
codercat: но все же я бы рекомендовал сначала сделать снепшот, благо это дело минут 10 со всеми установками софтин, и если действительно изза базы то выбрать самый жирный запрос и его профилировать в heidisql
codercat: если вы в этом уверены (а чтобы в этом убедиться то нужно просто сделать какойнить запрос к базе и убедиться что ждете долго) то тогда рекомендую скачать бесплатную софтину heidisql. там есть встроенный профилировщик запросов., он покажет на чем конкретно тормозит запрос
