- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Попробуйте хотя бы себе объяснить, каким же интересно образом приложение будет медленнее генерировать код, если канал занят? С помощью какого интересно механизма будет медленнее или быстрее работать PHP (или любой другой язык взять) код, или код хранимой процедуры или SQL запроса в зависимости от занятости канала? Что, есть какие-то специальные каналы для посылки от стека TCP/IP в программу команд типа "а ну ка помедленнее, братишка, я печатать в сокет не успеваю"?
Слово многопотчность вам знакомо? А понятие блокирующей операции?
Если да.
Предположим что вы читаете из сокета. что будет если вы вызвали метод read а данных нет.
Предположим что вы пишете в сокет, что будет если вы вызвали метод write а исходящий буфер переполнен?
Правильный ответ: текущий поток перейдет в состояние ожидания.
ЗЫ. Кстати 6 лимонов показов в час это на одной машине или на кластере? Поподробнее пожалуйста. Уж очень интересно как добились такой производительности 7 лет назад
Читая обрывочные сведения в этом топике я могу предположить, что Вы добавляете в страницу не HTML код, как Вы говорите, а Вы пробуете выводить разное количество каких блоков на странице которые берутся вероятно из базы. Естественно СЛЕДСТВИЕМ этого является увеличение количества HTML кода. Естественно и то, что при выводе 3 блоков и 5 блоков с данными из базы на странице у вас могут увеличиваться затраты на выборку данных из базы или затраты на обработку данных (в слове бизнес-логики). Это зависит уже от архитектуры приложения. Если это так, что удивляться, что приложение дольше работает при выводе 5 блоков в отличие от 3 нет смысла - это естественно. Нужно брать каждый блок вывода и смотреть - сколько времени он работает и почему.
Нет. Одна и та же страница с одним и тем же кол-вом блоков открывалась с соединения 96/32 и с соединения 1024Mбит. В одном случае время генерации кода 36 секунд, в другом - доли секунды.
Предположим что вы пишете в сокет, что будет если вы вызвали метод write а исходящий буфер переполнен?
Правильный ответ: текущий поток перейдет в состояние ожидания.
В зависимости от реализации. На том уровне о котором мы говорим (вывод страницы средствами веб-сервера, генерация данных - веб приложением) таким образом Вы буфер отправки не переполните. Напишите такой скрипт, покажите что буфер переполняется и скрипт тормозится отправкой данных, тогда будем спорить дальше.
Исходя из ваших утверждений получается что медленный клиент (например на модеме 1200 бод - у меня есть такой в коллекции) может очень нехило притормозить серверную процедуру? Тогда это была бы вешалка для любого хостинга.
ЗЫ. Кстати 6 лимонов показов в час это на одной машине или на кластере? Поподробнее пожалуйста. Уж очень интересно как добились такой производительности 7 лет назад
На кластере, само собой. Что никак не умаляет сложности задачи, решаемой группой разработки в то время, думаю Вы понимаете.
В зависимости от реализации. На том уровне о котором мы говорим (вывод страницы средствами веб-сервера, генерация данных - веб приложением) таким образом Вы буфер отправки не переполните. Напишите такой скрипт, покажите что буфер переполняется и скрипт тормозится отправкой данных, тогда будем спорить дальше.
На псевдо языке можно?
засечь время
записать в вывод 10 мульенов нулей
вывести время
могу на жабе
long t1 = System.currentTimeMillis();
byte[] data = new byte[10*1024*1024];
response.getOutputStream().write(data);
logger.info("Время: "+(System.currentTimeMillis()-t1));
Исходя из ваших утверждений получается что медленный клиент (например на модеме 1200 бод - у меня есть такой в коллекции) может очень нехило притормозить серверную процедуру? Тогда это была бы вешалка для любого хостинга.
Все верно только не понял почему вешалка?:-)) поток то обсуживающий данного клиента будет 99% времени своего исполнения ожидать доступности канала (т.е ничего не делать)
На кластере, само собой. Что никак не умаляет сложности задачи, решаемой группой разработки в то время, думаю Вы понимаете.
Хотелось бы все таки узнать поподробнее.
Хотелось бы все таки узнать поподробнее.
Что подробнее то? Про архитектуру проекта рассказывать не буду. Назывался AdWatch (и сейчас так называется), кто в теме - знает что это за зверь.
2 ТопикСтартер: вот вам ссылка - может пригодится. http://php.russofile.ru/ru/translate/unsort/chachig_in_php
На псевдо языке можно?
засечь время
записать в вывод 10 мульенов нулей
вывести время
могу на жабе
long t1 = System.currentTimeMillis();
byte[] data = new byte[10*1024*1024];
response.getOutputStream().write(data);
logger.info("Время: "+(System.currentTimeMillis()-t1));
Да на чем угодно, вы оттестируйте в буферизированном виде и в небуферизированном и приходите с конкретными данными.
Все верно только не понял почему вешалка?:-)) поток то обсуживающий данного клиента будет 99% времени своего исполнения ожидать доступности канала (т.е ничего не делать)
Да, идея понятна, но почему Вы считаете, что процесс построения страницы не работает в еще одном отдельном потоке, который просто обрабатывает данные? Он помещает их в определенный межпроцессный буфер, а вот из него уже другой процесс внутри сервера приложения (в нашем примере PHP движок под сервером) будет перегружать данные в сокеты. Именно он уже может ждать пока освободится канал, но он обязан работать независимо от процесса, который формирует данные, поскольку это вообще логически задачи разных слоев архитектуры. Если это не так - это ошибка в архитектуре сервера приложений. Я очень сильно сомневаюсь что найдется такой кривой application сервер, но если Вы можете доказать что он существует экспериментальными данными - давайте, мне самому интересно.
Да, идея понятна, но почему Вы считаете, что процесс построения страницы не работает в еще одном отдельном потоке, который просто обрабатывает данные? Он помещает их в определенный межпроцессный буфер, а вот из него уже другой процесс внутри сервера приложения (в нашем примере PHP движок под сервером) будет перегружать данные в сокеты. Именно он уже может ждать пока освободится канал, но он обязан работать независимо от процесса, который формирует данные, поскольку это вообще логически задачи разных слоев архитектуры. Если это не так - это ошибка в архитектуре сервера приложений. Я очень сильно сомневаюсь что найдется такой кривой application сервер, но если Вы можете доказать что он существует экспериментальными данными - давайте, мне самому интересно.
Вы надо мной издеваетесь? Вам ergo привел пример что у него разное время.
Насчет двух потоков: ясное дело что отсылает данные другой поток. но размер промежуточного буфера не бесконечен и пока он полный исполняющийся поток будет ожидать освобождения этого буфера.
Попробуйте хотя бы написать скрипт отдающий пользователю гигабайтный файл. За какое время отработает данный скрипт? За время необходимое для прочтение данного файла с диска?
ЗЫ. Нужно понимать что буферы ввода/выводе нерезиновые.
ЗЫЫ. Любой вебсервер при определенных размерах генерируемого вывода заставит генерирующий поток ожидать (при условии что скорость генерации данных больше скорости передачи)
Тьфу ты, это Вы издеваетесь. Кто ж спорит то с этим? Это очевидно.
Вообще-то, я начал с того, что задачу по выяснению что именно тормозит в веб-приложении нужно разбить на части и соответственно все промерить в нужных точках. А Вы мне пишете какие-то очевидные вещи чисто теоретического плана. У ТС же не гигабайтные страницы отдаются, я надеюсь.
Тут вопрос нужно было ставить иначе - что именно показывают счетчики времени по коду и можно ли на них полагаться при нагрузочном тестировании, или по крайней мере какие выводы из них делать нужно, а какие - нет.
Короче надо завязывать с этим базаром, я чувствую. Кому-то помогать всегда себе дороже выходит.
ЗЫ: В любом случае спасибо за оппонирование, кое-чего освежилось в памяти.
Тут вопрос нужно было ставить иначе - что именно показывают счетчики времени по коду и можно ли на них полагаться при нагрузочном тестировании, или по крайней мере какие выводы из них делать нужно, а какие - нет.
В самом начале топика есть ссылка на php-код который отвечает за подсчет времени генерирования страницы.