Высокие нагрузки

[phillip]

но, ничто не мешает мне использовать одновременно допустим мускуль, и APC так как APC кеширует скомпилированный код моего скрипта. Правильно я понимаю?

вот кстати результат работы Для просмотра ссылки Войди или Зарегистрируйся Линки на странице генерируются динамически, и являются тем самым проблемным местом.

А есть ли готовые скрипты, которыми можно нагрузить этот сайт, и сразу посмотреть, при каких нагрузках падение происходит, ну и прочую статистику?

 

[Abliganto]

но, ничто не мешает мне использовать одновременно допустим мускуль, и APC так как APC кеширует скомпилированный код моего скрипта. Правильно я понимаю?

Кашу маслом не испортишь Вам нужно чётко понимать зачем используется какая конструкция. Если говорить о макс. повышении производительности, то надо убрать все include, всё свалить в один большой файл (по крайней мере на продакшене) и + APC даст хороший прирост производительности на ровном месте, если изначально инклудилось много файлов.

От чего нельзя избавиться, так это от сетевой нагрузки, клиенты всегда будут слегка подтормаживать.

P.S. ссылки надо заключать в HIDE

Вот случайно обнаружил пример как ускорить чтение строк из файла (если ещё актуально)

 

[phillip]

Интересный пример, спасибо! но уж если из БД будет быстрее чем из файла, сделаем из БД. кстати раньше мне тут на нулледе еще советовали использовать БД типа беркли. (функции в пхп начинающиеся на dba_ ). Я читал, пишут что в поисковиках пользуются такими БД именно. Может быть лучше подключить эти самые dba_ вместо мускуля, с таблицами хранящимися в оперативке?

Запустил еще ab (апач бенчмарк) на вдсе. Другие скрипты, которые без этой системы с взятием строк из файла- норм работают. а вот то что мы обсуждаем тут- показало вот чего :bc: :

Concurrency Level: 10
Time taken for tests: 2.907419 seconds
Complete requests: 500
Failed requests: 498
(Connect: 0, Length: 498, Exceptions: 0)
Write errors: 0
Total transferred: 750165 bytes
HTML transferred: 654225 bytes
Requests per second: 171.97 [#/sec] (mean)
Time per request: 58.148 [ms] (mean)
Time per request: 5.815 [ms] (mean, across all concurrent requests)
Transfer rate: 251.77 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 9 57 289.2 15 2085
Waiting: 9 57 289.1 15 2085
Total: 9 57 289.2 15 2085

Percentage of the requests served within a certain time (ms)
50% 15
66% 17
75% 18
80% 19
90% 22
95% 28
98% 2073
99% 2080
100% 2085

Я сделал 500 запросов, и из них 498- провальные. уууу жесть жестянка. и это именно вот на этом скрипте, все остальные- 0 провальных. крутой скрипт вообщем
И что значит последняя таблица, не совсем понимаю

 

[Abliganto]

Интересный пример, спасибо! но уж если из БД будет быстрее чем из файла, сделаем из БД. кстати раньше мне тут на нулледе еще советовали использовать БД типа беркли. (функции в пхп начинающиеся на dba_ ). Я читал, пишут что в поисковиках пользуются такими БД именно. Может быть лучше подключить эти самые dba_ вместо мускуля, с таблицами хранящимися в оперативке?

Насколько я знаю это такие же текстовые файлы, в которых все строки дополнены пробелами до одинаковой ширины. Есть ещё SQLite на файлах, но надо тестировать на производительность все приведённые решения, так мы лишь тычем пальцем в небо К счастью все решения достаточно просты и их можно лего протестировать на windows машине, с линуксом сложнее, т.к. могут быть траблы с установкой модулей Правда я для разработки использую только Linux в вирт. машине, а десктоп под виндой. Скорость между виндовым веб-сервером и линусовым значительна.

Запустил еще ab (апач бенчмарк) на вдсе. Другие скрипты, которые без этой системы с взятием строк из файла- норм работают. а вот то что мы обсуждаем тут- показало вот чего :bc: :
Я сделал 500 запросов, и из них 498- провальные. уууу жесть жестянка. и это именно вот на этом скрипте, все остальные- 0 провальных. крутой скрипт вообщем

Документацию к ab вы конечно не читали? Там чётко сказано, что успешной попыткой является страница 1 в 1 равная результату первого запроса, а если на странице динамически меняется текст, тогда будет столько много "провальных"

 

[phillip]

Документацию к ab вы конечно не читали? Там чётко сказано, что успешной попыткой является страница 1 в 1 равная результату первого запроса, а если на странице динамически меняется текст, тогда будет столько много "провальных"

Аааа вон как. А как тогда нагрузить скрипт, проверить его в работе?

Скорость между виндовым веб-сервером и линусовым значительна.

линуксовый быстрее?

 

[Abliganto]

Аааа вон как. А как тогда нагрузить скрипт, проверить его в работе?
линуксовый быстрее?

Вы его уже проверили. Запросы-то были отправлены.

на 10 потоках
Requests per second: 171.97 [#/sec] (mean)

теперь возьмите пустой скрипт который ничего не делает, только возвращает столько же текста, сколько и тестируемый и станет ясно какая производительность может быть на тестируемом сервере (но естественно её нереально достичь).

Линукс быстрее работает с файловой системой, даже в виртуалке. Но не нужно забивать себе этим голову.

Я думаю, вы уже получили максимум информации, советую испробывать самый простой подход с MySQL, если производительность будет достаточна, на этом можно всё и оставить до тех пор, пока снова не встанет вопрос. Иначе можно безуспешно гнаться за призраком Я на днях оптимизировал одну регулярку, прирост производительности был в > 100 раз (на какие-то микросекунды). Если бы обрабатываемых данных было 100 строк, я бы даже не заморачивался, а т.к. их было больше миллиона, я сэкономил часов 5 серверного времени

 

[phillip]

ого! да уж, микросекунды сыграли роль)
почитал первую страницу снова, получается с ваших слов, мускуль может выдержать 100 запросов в секунду? Тогда 6000 запросов в минуту. Это же мало вроде) Там гугл шарится у меня сильно.

Ну ладно, видно будет. Я решил применить такую тактику.
1)Делаю таблицу в мускуле, с двумя полями.
Тип таблицы- мемори, поля- id, txt.
id- автоинкремент, int
txt- char. Хотел varchar, но надо указывать максимальный размер строки, а я ее не знаю.
При этом! нам ведь надо дергать ни одну строку, а от 5 до 10 допустим. Поэтому я хочу в одну ячейку загнать сразу 3 строки из текстового файла. Кол-во обращений к БД уменьшится. Правильно я рассуждаю? Или не стоит так делать?

Вот. А кол-во айди мы знаем, поэтому а) юзаем srand(mt_rand()); mt_rand; и не юзаем ORDER BY RAND в самом запросе. Тем самым получается быстрее всего достать случайные значения.

При этом я так понял что постоянных соединений держать не стоит, поэтому я в начале скрипта делаю mysql_connect() и по завершению работ пишу mysql_close().

2)Затем устанавливаю APC чтобы кешировать скомпилированный пхп код.
3)избавляюсь от курла, чтобы клиент не обращался на серверную часть на том же вдсе, а просто сам лез в БД.

Все верно? Утверждайте, и я приступаю к выполнению)))

 

[Abliganto]

ого! да уж, микросекунды сыграли роль)
почитал первую страницу снова, получается с ваших слов, мускуль может выдержать 100 запросов в секунду? Тогда 6000 запросов в минуту. Это же мало вроде) Там гугл шарится у меня сильно.

Это зависит от запросов. К примеру поиск по таблице с 20 или 200 тыс. строк по примари кею занимает 0.0004 секунды, можно предположить, что 1000 таких запросов в секунду он легко обработает Не надо верить всему что пишут, у каждого своя ситуация.

Ну ладно, видно будет. Я решил применить такую тактику.
1)Делаю таблицу в мускуле, с двумя полями.
Тип таблицы- мемори, поля- id, txt.
id- автоинкремент, int
txt- char. Хотел varchar, но надо указывать максимальный размер строки, а я ее не знаю.

Сколько в таблице будет записей? 200 тысяч? Вам вполне хватит mediumint unsigned

Длина строки - макс. длина строки думаю не привысит 255 символов для кея? Юзайте варчар 255. CHAR вообще трогать не надо, он статичного размера!!!

При этом! нам ведь надо дергать ни одну строку, а от 5 до 10 допустим. Поэтому я хочу в одну ячейку загнать сразу 3 строки из текстового файла. Кол-во обращений к БД уменьшится. Правильно я рассуждаю? Или не стоит так делать?

Не надо думать что БД глупа, у меня в таблицах по 10млн записей и шустро работает. 1 запись = 1 кей. Запрос будет всего один SELECT `название текстового поля` WHERE `id` IN ( через запятую список рандомных ИД, которые вы сгенерили в ПХП )

Вот. А кол-во айди мы знаем, поэтому а) юзаем srand(mt_rand()); mt_rand; и не юзаем ORDER BY RAND в самом запросе. Тем самым получается быстрее всего достать случайные значения.
При этом я так понял что постоянных соединений держать не стоит, поэтому я в начале скрипта делаю mysql_connect() и по завершению работ пишу mysql_close().
2)Затем устанавливаю APC чтобы кешировать скомпилированный пхп код.
3)избавляюсь от курла, чтобы клиент не обращался на серверную часть на том же вдсе, а просто сам лез в БД.
Все верно? Утверждайте, и я приступаю к выполнению)))

Если всё на одном сервере, то курл лучше убрать, прирост будет раз в 100 на сетевых коммуникациях Чем меньше телодвижений, тем быстрее. Дерзайте

 

[phillip]

а насчет типа БД, memory стоит поставить?

 

[Abliganto]

а насчет типа БД, memory стоит поставить?

Не надо делать предоптимизацию. Если вы поставите мемори, то все данные сотрутся после рестарта сервера БД, нужно будет их туда снова засунуть, если они исчезнут. Возможно выигрышь будет в тысячрые микросекунды и ничего не даст, только время зря потратите. Лучший способ - сделать 2мя способами и сравнить Возможно в вашем случае не будет необходимого объёма оперативки или такого типа таблиц.