Сильно тормозят ссылки прописанные через mod_rewrite

Sha писал:

С file_get_contents разобрались уже. Его прожорливость следствие того что возвращается не ссылка, а значение.

Ну и утерся бы уже, и молчал. Нет же...

Sha писал:

Какая связь асинхронности со скоростью передачи данных? Диски быстрее крутятся или сетевые адаптеры несущую частоту повышают?

И кернел у тебя, и твое приложение работают в разных кольцах CPU, и делая _любые_ операции по перегонке данных через userspace ты напарываешься на кучи контекстных переключений. Но про это ты, конечно же, не в курсе. Про то, что и дисковые контроллеры, и сетевые карты поддерживают DMA и в sendfile могут обмениваться данными вообще без участия CPU - тоже не представляешь. Про то, насколько дороги на самом деле треды для системы, когда их сотни - забыл подумать. Плюс вышеуказанные переключения контекста на каждый в изобилии... Нет, все ж железом только определяется, не софтом - тогда нахуй юникса, давай на DOS все напишем в циклах на бейсике будем данные по буферам гонять - будет очень быстро работать и шикарно масштабироваться, да?

Цитата:

А буферы ядром используются те же самые. Асинхронность может помочь в многопотоковости и многозадачности. Но никак не осуществить этот ввод-вывод.

А так ты типа на одно соединение рассчитываешь?

Надоело с твоими фантазиями спорить уже

Dr.Syshalt писал:

Ну и утерся бы уже, и молчал. Нет же... И кернел у тебя, и твое приложение работают в разных кольцах CPU, и делая _любые_ операции по перегонке данных через userspace ты напарываешься на кучи контекстных переключений. Но про это ты, конечно же, не в курсе. Про то, что и дисковые контроллеры, и сетевые карты поддерживают DMA и в sendfile могут обмениваться данными вообще без участия CPU - тоже не представляешь.

Кольца, контексты. Не надо блистать банальностями и заниматься шарлатанством.
Ещё раз напишу (хз будет ли толк)
1) mmap + send - нет перегонки данных через юзерспейс. В этом фактически весь смысл mmap.
2) система использует асинк и ДМА при передаче как от sendfile так и от send.
3) send не прыгает из кольца в кольцо. у ядра хватит полномочий добраться до страниц пространства задачи, вкачивать и лочить физические страницы в RAM по мере необходимости и отдать драйверу карты ссылки.
3а) система давно не копирует из буфера в буфер. вместо этого используются указатели и адресная арифметика. ДАЖЕ если send делать из юзерспейса.

Сегодня все разговоры про массовые и дорогостоящие бкопи не более чем винтаж.

А про прямую передачу ДМА я даже больше скажу. Прямая передача диск-сетеваякарта (если система до такого додумается) означает что данные минуют файловый кеш. И в то время как моя система будет отдавать статический видеоконтент нескольким пользователям на несколько сетевых карт из файлового кеша ваша будет каждый раз осуществлять одиночную передачу только на одну карту и занимать: а) канал интерфейса диска (скази, сата или что там у вас), б) мастер-ДМА контроллера диска (если диск будет мастером припередачи) в) изнашивать диск (8mb кеша не спасут при наших масштабах) г) дергаться по прерываниям IO.
Более того, если передача идёт "прямо" в сетевую карту и карта сидит на PCI, то надо учитывать, что ресурсы эти будут заняты не протяжении относительно долгого времени.

Вот вам и масштабируемость.

Вам для запоминания: Если система в состоянии реализовать sendfile c использованием ДМА, асинхронного ввода-вывода и любой другой высокой технологии, то send так же использует эти возможности.

Цитата:

Про то, насколько дороги на самом деле треды для системы, когда их сотни - забыл подумать. Плюс вышеуказанные переключения контекста на каждый в изобилии... Нет, все ж железом только определяется, не софтом - тогда нахуй юникса, давай на DOS все напишем в циклах на бейсике будем данные по буферам гонять - будет очень быстро работать и шикарно масштабироваться, да? А так ты типа на одно соединение рассчитываешь? Надоело с твоими фантазиями спорить уже

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

Sha писал:

Кольца, контексты. Не надо блистать банальностями и заниматься шарлатанством. Ещё раз напишу (хз будет ли толк) 1) mmap + send - нет перегонки данных через юзерспейс. В этом фактически весь смысл mmap.

Ага. Иди уже, Мурзилку читай, школота

http://www.linuxjournal.com/article/6345
http://articles.techrepublic.com.com/5100-10878_11-1044112.html

пойнтер на страницы ты в кернеле, что ли, имеешь, после вызова mmap?

Цитата:

With the sendfile() zero-copy approach, the data is read immediately from the disk into the OS cache memory using Direct Memory Access (DMA) hardware, if possible. The TLB cache is left intact. The performance of applications utilizing sendfile() primitive is high because this system call does not directly point to memory and, therefore, minimizes performance overhead. Data to be transferred is usually taken directly from system buffers, without context switching, and without trashing the cache. Thus, the usage of sendfile() in server applications can significantly reduce CPU load. Replacing read() with mmap() in our example will not change much. However, the mmap syscall is asking to map some bytes from the file (or other object) specified by the file descriptor into virtual memory. Attempting to read data from this memory will result in disk operations. With this call we can eliminate read operations because the system will write mapped memory directly into the socket without calling read() explicitly and without buffer allocation. Nevertheless, this operation does cause the TLB cache flushing, so CPU load per byte transferred will be higher.

Вопросы? Хотя какие вопросы могут быть от человека, который контекстные свичи с копированием путает.. наверное, очень много вопросов.

Цитата:

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

И предполагается, что я тебе сейчас начну объяснять, что в серверных кернелах линукса используется voluntary preemption и, пока syscall не завершится, его никто не трогает и контексты не переключает? И как раз именно это сделано для максимальной производительности, а на десктопе, особенно там, где требуется минимальная латентность, типа real time, используют другую модель преемпшена? Да пусть тебе лучше в школе расскажут. Кернел-то хоть раз сам собирал? Там же вопрос задает конфиг, как раз про это.

Мурзилку! Понял? Читай Мурзилку. Потому что даже из мурзилок типа linuxjournal ты и то можешь много для себя нового узнать. Там тебе и чудные картинки, и большие буквы.

Еще "шарлатаном" называет... ламо. Есть старое определение ламера - это "чайник, вообразивший себя хакером". К тебе очень хорошо подходит.