- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Сервер от Hetzner. Ubuntu 18.04.
При запуске такого скрипта
из командной строки время выполнения составляет в среднем:
Если через браузер смотреть на это скрипт, то время будет другое:
Это почти в три раза медленнее.
Если поставить ubutu 16.04, то в ней оба варианта быстро работают.
Обе установки с нуля + установка только apache и php
Пробовал отключать opcache, время обработки через апач возрастает примерно до 0,0020. На cli не действует, так же.
Помогите определить где находятся тормоза. Как вычислить, какая настройка не работает или не включена?
Никто так бенчмарки не делает, особенно на таком коде, который работает за миллисекунды. Тем более, вы не сказали какая версия PHP (в репозиториях 16.04 и 18.04 могут быть разные). CLI без opcache по дефолту работает.
ну это логично что cli из консоли будет быстрее апача. так и должно быть.
ну это логично что cli из консоли будет быстрее апача. так и должно быть.
Это было бы логично, если бы мы мерили скорость выполнения не участка кода, а время от запроса, до получения результата. В чем логичность?
Никто так бенчмарки не делает, особенно на таком коде, который работает за миллисекунды. Тем более, вы не сказали какая версия PHP (в репозиториях 16.04 и 18.04 могут быть разные). CLI без opcache по дефолту работает.
В 16.04 php7.0, в 18.04 php 7.2
Эти доли секунд влияют на прогрузку страницы. Я это визуально вижу. Я взял новый сервер для переноса со старого, поэтому имею возможность сравнить.
Вот например старый сервер:
Цифры меняются конечно. Есть и 0.00042 и 0.00072. Я привожу примерно средние значения, которые часто появляются.
Старый сервер под нагрузкой, хоть и не большой но всё же.
Сейчас на новый сервер поставил 16.04. Установил apache php. Перезагрузил, стало так.
ХМ, пару минут поработал на 16.04 и стало так
Да, после перезагрузки работает норм всего лишь пару минут.
Не пойму что ему нужно.
Может ему нагрузка нужна?
Не понимаю, в чем проблема? Такое поведение вполне нормальное и не на что не влияет, не нравится веб сервер - ставьте другой
Ну всё правильно. CLI это CLI, апатч это апатч. В чём вопрос то?
---------- Добавлено 08.08.2018 в 22:31 ----------
Ненравиться апатч, ставьте nginx проверьте с ним.
Не понимаю, в чем проблема? Такое поведение вполне нормальное и не на что не влияет, не нравится веб сервер - ставьте другой
Так как бы не нормально. На трех серверах время выполнения одинаковое. Здесь же тормоза какие то. Вот и пытаюсь понять в чем причина.
---------- Добавлено 08.08.2018 в 22:31 ----------
Ненравиться апатч, ставьте nginx проверьте с ним.
Ставил, то же самое.
Получается у PHP какая то проблема. И ведь не узнать. Может какого пакета не хватает или нагрузки. Сегодня попробую на время пользователей перевести на новый серв.
Vanzent, придумайте другой тест, который идет подольше, хотябы секунду, а не тысячные доли секунды, потому что текущая разница это меньше чем размер возможной погрешности.
Vanzent, придумайте другой тест, который идет подольше, хотябы секунду, а не тысячные доли секунды, потому что текущая разница это меньше чем размер возможной погрешности.
Это не погрешность. В три раза уж точно.
погрешность - это когда пишу 0,00038, а на самом деле:
0.00038156
0.00038345
0.00038083
0.00038123
На трех серверах время выполнения одинаковое. Здесь же тормоза какие то. Вот и пытаюсь понять в чем причина.
Не задумывались о разном физическом оборудовании серверов?