Берётся прикидка «юзер смотрит на нашем сайте одну страницу в течение полутора минут». Гугль аналитикс вроде бы даёт точную цифру. Дальше, будем считать приемлимым, если 90% юзерей будут обслужены за 2 секунды. Берётся ab и подбирается количество потоков, которые влезают в этот отклик. Я бы оценил в ~30 потоков, исходя из моей статистики на 200. Т.е. у нас есть 30 rps и один юзер генерирует 0.0(1) rps. Итого, сайт держит (оценка сверху) ~3k онлайн. Неплохо. И ничего, кроме ab и аналитики. Эта оценка потом понижается за счёт отдельных медленных страниц — но их время отклика (и нагрузка на сервер) мереется тем же ab.
ab — это очень мощный инструмент, который надо правильно использовать. Любая заданная нагрузка на любое время. Есть некоторые области, которые им мерить неудобно/невозможно — но не приведённый сайт.
Тогда это будет тест базы, а не веб-сервера. А база обычно кладётся поисковыми запросами — мало кто защищается заранее. В общем, чуть другое направление.
Апач — это либо конфигурироемость пользователем (+всякие обёртки над пхп для исполнения под конкретным uid), либо специфические модули. Если первое — лайти подойдёт, но тут уж лучше nginx+php-fpm, имхо. А во 2м — никуда не деться.
Мне тут понадобилось потестировать отдачу статики с диска. ab умеет только один урл запрашивать (я могу и внутри урла генерировать случайный X-Accel-Redirect, но сначала не стал) — решил попробовать siege, у него такая вещь есть. Итого:
— тест на 1 файл, отдаваемый из файлового кэша — siege на полпорядка медленее
— при попытке прочитать 6МБ файл с урлами для перебора — съел гиг оперативы и был убит.
Так что siege неюзабелен по моему мнению. Почему его тогда так любят?)
По результатам, примерно так:
апач ограничен правильно, раз не выжирает память и не уходит в своп
но страницы генерируются черезвычайно медленно (отдаются, надеюсь, nginx'ом и быстро)
Time per request: 8273.03 [ms] (mean)
Кэширование (nginx'ом) для неавторизированных пользователей страниц сильно бы помогла.
И вопрос — почему на графиках interrupts не видно?
Cовет — обновите nginx. Или пропатчите. Т.к. он по последней уязвимости у вас убивается в корку. При помощи аб — добро пожаловать в Internal Server Error.
Кстати, случайно наткнулся на ещё одно интересное решение, основанное на встроенном типе box. Итоговый выигрыш — того же порядка, что и ip4r (GIN бы ему :))
postgres=# EXPLAIN ANALYZE SELECT * FROM testip WHERE 19999999 BETWEEN startip AND endip;
QUERY PLAN
----------------------------------------------------------------
Seq Scan on testip (cost=0.00..19902.00 rows=200814 width=12) (actual time=3.457..434.218 rows=1 loops=1)
Filter: ((19999999 >= startip) AND (19999999 <= endip))
Total runtime: 434.299 ms
(3 rows)
Time: 435,865 ms
postgres=# CREATE INDEX ggg ON testip USING gist ((box(point(startip,startip),point(endip,endip))) box_ops);
CREATE INDEX
Time: 75530,079 ms
postgres=# EXPLAIN ANALYZE
SELECT *
FROM testip
WHERE box(point(startip,startip),point(endip,endip)) @> box(point (19999999,19999999), point(19999999,19999999));
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on testip (cost=60.50..2550.14 rows=1000 width=12) (actual time=0.169..0.172 rows=1 loops=1)
Recheck Cond: (box(point((startip)::double precision, (startip)::double precision), point((endip)::double precision, (endip)::double precision)) @> '(19999999,19999999),(19999999,19999999)'::box)
-> Bitmap Index Scan on ggg (cost=0.00..60.25 rows=1000 width=0) (actual time=0.152..0.152 rows=1 loops=1)
Index Cond: (box(point((startip)::double precision, (startip)::double precision), point((endip)::double precision, (endip)::double precision)) @> '(19999999,19999999),(19999999,19999999)'::box)
Total runtime: 0.285 ms
(5 rows)
Time: 2,805 ms
ab — это очень мощный инструмент, который надо правильно использовать. Любая заданная нагрузка на любое время. Есть некоторые области, которые им мерить неудобно/невозможно — но не приведённый сайт.
Benchmarking www.avtoturistu.ru (be patient) Finished 7255 requests Server Software: nginx/0.6.32 Server Hostname: www.avtoturistu.ru Server Port: 80 Document Path: /page/trassy Document Length: 193 bytes Concurrency Level: 200 Time taken for tests: 300.104 seconds Complete requests: 7255 Failed requests: 6819 (Connect: 0, Length: 6819, Exceptions: 0) Broken pipe errors: 0 Non-2xx responses: 596 Total transferred: 112298400 bytes HTML transferred: 109603592 bytes Requests per second: 24.17 [#/sec] (mean) Time per request: 8273.03 [ms] (mean) Time per request: 41.37 [ms] (mean, across all concurrent requests) Transfer rate: 374.20 [Kbytes/sec] received Connnection Times (ms) min mean[±sd] median max Connect: 23 294 957.0 23 9496 Processing: 47 7246 6284.1 3668 126392 Waiting: 23 7245 6284.1 3667 126391 Total: 47 7540 6265.4 3799 135887 Percentage of the requests served within a certain time (ms) 50% 3798 66% 6226 75% 7169 80% 8777 90% 13697 95% 24762 98% 51959 99% 66070 100% 135887 (last request)— тест на 1 файл, отдаваемый из файлового кэша — siege на полпорядка медленее
— при попытке прочитать 6МБ файл с урлами для перебора — съел гиг оперативы и был убит.
Так что siege неюзабелен по моему мнению. Почему его тогда так любят?)
апач ограничен правильно, раз не выжирает память и не уходит в своп
но страницы генерируются черезвычайно медленно (отдаются, надеюсь, nginx'ом и быстро)
Time per request: 8273.03 [ms] (mean)
Кэширование (nginx'ом) для неавторизированных пользователей страниц сильно бы помогла.
И вопрос — почему на графиках interrupts не видно?
Посмотрим, посмотрим, хе-хе))
ЗЫ: за bless({}, ref $invocant || $invocant) я бы лично закапывал на месте :) Не должно быть возможности вызвать new() на объекте.
postgres=# EXPLAIN ANALYZE SELECT * FROM testip WHERE 19999999 BETWEEN startip AND endip; QUERY PLAN ---------------------------------------------------------------- Seq Scan on testip (cost=0.00..19902.00 rows=200814 width=12) (actual time=3.457..434.218 rows=1 loops=1) Filter: ((19999999 >= startip) AND (19999999 <= endip)) Total runtime: 434.299 ms (3 rows) Time: 435,865 ms postgres=# CREATE INDEX ggg ON testip USING gist ((box(point(startip,startip),point(endip,endip))) box_ops); CREATE INDEX Time: 75530,079 ms postgres=# EXPLAIN ANALYZE SELECT * FROM testip WHERE box(point(startip,startip),point(endip,endip)) @> box(point (19999999,19999999), point(19999999,19999999)); QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on testip (cost=60.50..2550.14 rows=1000 width=12) (actual time=0.169..0.172 rows=1 loops=1) Recheck Cond: (box(point((startip)::double precision, (startip)::double precision), point((endip)::double precision, (endip)::double precision)) @> '(19999999,19999999),(19999999,19999999)'::box) -> Bitmap Index Scan on ggg (cost=0.00..60.25 rows=1000 width=0) (actual time=0.152..0.152 rows=1 loops=1) Index Cond: (box(point((startip)::double precision, (startip)::double precision), point((endip)::double precision, (endip)::double precision)) @> '(19999999,19999999),(19999999,19999999)'::box) Total runtime: 0.285 ms (5 rows) Time: 2,805 ms© www.postgres.cz/index.php/PostgreSQL_SQL_Tricks