Какой script time и usage memory благоприятный для низка нагруженой и высоко нагруженой системы.
К примеру есть данные
Script time (microtime - microtime old) 0.222
Usage memory 256 Кб.
Насколько они хороши? Какие хорошие цифры для хай-лоад в 1000 уникалов на день?
_____________
Трус не играет в хокей
brevis
11.05.2015 - 21:24
Чувак, у тебя точно 7 лет опыта?
_____________
Чатик в телеге
paul85
11.05.2015 - 21:27
Цитата (stump @ 11.05.2015 - 20:50) |
Script time (microtime - nicrotime old) 0.222 |
Очень много. Хорошо, когда не более 0,02. В любом случае ИМХО никак не более 0,1
Цитата (stump @ 11.05.2015 - 20:50) |
Usage memory 256 Кбит. |
Это вообще характеристика скорости. В этих единицах не измеряется объем памяти. 256Кбайт - это хорошо.
Да уж, вопрос оч. странный...
Цитата (brevis @ 11.05.2015 - 21:24) |
Чувак, у тебя точно 7 лет опыта? |
Читать умеешь: давайте побеседуем!
_____________
Трус не играет в хокей
inpost
11.05.2015 - 21:39
stumpнет закономерностей. Игры могут грузиться 2-5-10 секунд, а потом летают. Попробуй включить на видео-чатах свою камеру, она включится через 1-2 секунды только, если не все 3-4.
Хотя по правде говоря для простой главной страницы было бы очень много 0.2 сек, тогда надо всё кешировать, что медленно обрабатывается. К тому же очень часто можно увидеть, что весь сайт открывается за 0.001 сек, а лишь 1 неоптимизированный запрос идёт 0.2 сек, а это уже много для запроса такого, его результаты снова же кешировать лучше.
И почему так мало мемори используется? Ты не пик смотрел?!
_____________
Обучаю веб-программированию качественно и не дорого:
http://school-php.comФрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Не пик. Это одна из страниц. На IIS первая загрузка 0.222 последующие ~0.08. Решил что особенность IIS, а потом он половину кэширует и шустрит. Апач вроде шустрит сразу.
_____________
Трус не играет в хокей
paul85
11.05.2015 - 21:54
stump, есть такая утилитка, называется ApacheBench (ab). С помощью нее можно примерно понять сколько запросов в секунду выдерживает сервер. И с какой скоростью отвечает при одновременных запросах.
Например:
ab -c 10 -n 100 http://cf-parts.hm/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking cf-parts.hm (be patient).....done
Server Software: Apache
Server Hostname: cf-parts.hm
Server Port: 80
Document Path: /
Document Length: 15563 bytes
Concurrency Level: 10
Time taken for tests: 2.478 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 1571600 bytes
HTML transferred: 1556300 bytes
Requests per second: 40.35 [#/sec] (mean)
Time per request: 247.839 [ms] (mean)
Time per request: 24.784 [ms] (mean, across all concurrent requests)
Transfer rate: 619.26 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 2
Processing: 104 242 41.7 253 310
Waiting: 101 235 41.0 243 301
Total: 104 242 41.7 253 311
Percentage of the requests served within a certain time (ms)
50% 253
66% 268
75% 274
80% 276
90% 289
95% 298
98% 303
99% 311
100% 311 (longest request)
paul85 пойду заюзаю.
_____________
Трус не играет в хокей
0.222 это уже переделаная архитектура. Вот я 2 месяца назад спроектировал стартап 12.5с авторизированная страница. Сейчас перепроектировал в третий раз - предполагаю результат улучшиться
.
_____________
Трус не играет в хокей
T1grOK
11.05.2015 - 22:56
Цитата (stump @ 11.05.2015 - 16:50) |
Какие хорошие цифры для хай-лоад в 1000 уникалов на день? |
Highload в униках не измеряется.
Highload может быть и при 100 уников или наоборот, не быть при 10000 уников.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
paul85
11.05.2015 - 23:12
Цитата (T1grOK @ 11.05.2015 - 22:56) |
Highload в униках не измеряется. |
А в чем измеряется? Если УГ, написанное неграмотно на медленном фреймворке обрабатывает каждый запрос по 10 секунд - это что же, хайлоад!?
Конечно же в количестве пользователей ИМХО... ТС дает скорость выполнения скрипта. Подразумевается, что он оптимизирован до адекватного состояния с учетом задачи.
Требуется рассчитать какое количество клиентов будет для проекта хайлоадом.
Я так понимаю данную ситуацию... =))
T1grOK
12.05.2015 - 09:41
100000 уников в сутки это много? Ну если рассматривать в масштабах дата центра, то это речь "ни о чем".
1000 уников это много? Если имеем VPS и сложную бизнес логику, с большим количеством расчетов, то возможно и много(возможно и вовсе неподъемно).
Higload начинается там, где нагрузка приближается к пределу ресурсов(порог производительности) и применении комплекса средств и методов для решения задач связанных с производительностью.
P.S. По аналогии с Highload - Big Data. Где начинается Big Data 1ГБ, 10ГБ, 1ТБ?
Big Data начинается там, где первоочередной становится проблема обработки данных. Это может быть и 100МБ.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
paul85
12.05.2015 - 10:51
Цитата (T1grOK @ 12.05.2015 - 09:41) |
Higload начинается там, где нагрузка приближается к пределу ресурсов(порог производительности) |
Ну и что же получается, что написанный хрен знает как через жопу сайт на фреймворке в случае 5$ VPS-ки это хайлоад... А ровно тоже самое, на том же сервере, только грамотно реализованное - это не хайлоад? )))
Не вижу никак ответа на этот вопрос...
То есть чем хуже программист - тем больше у него хайлоад проектов, так получается-то?
vasa_c
12.05.2015 - 12:33
Открою страшную тайну. Система, спроектированная под хайлоад, обычно жрёт больше и ресурсов и времени на один запрос.
_____________
Блог ГО |
Таблица символов Юникода |
Графомания
bestxp
12.05.2015 - 13:50
по мне так надо знать какой у тебя запас прочности и как выдержит он например если на сайт перейдет сразу 1000 человек и будет шутстрить по нему, 1000 размазать на день это не много
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.