Команду block SSI можно использовать только как stub в virtual?

["Демченко Вячеслав" <word2electronics@xxxxxxxxxxxxxx>]

Здравствуйте! 

Вопрос:
В текущей реализации команду block SSI можно использовать только как заглушку stub в virtual.

Есть ли какой либо другой варинт вывести block без использования virtual, по моему 
скромному мнению, это было бы очень удобно, плюс расширяются возможности в 
построении логики формирования ответа на уровне nginx, не в ущерб проиводительности, 
даже наооброт повышения.

Приведу результаты моих тестов.

Имеем шаблон SSI: 1.html. 

Блок который используется в 1.html, также вручную помещается в memcache.

И следующий конфиг:

        location /dynamic     { 
            internal;
            return 404;
        }
        
        #location /dynamic     { 
        #    internal;
        #    set             $memcached_key   "keymemcashe";
        #    memcached_pass  192.168.1.1:11211;
        #}

Тестировал ab следующим образом: ab -c 100 -n 500.

Результаты когда ответ формировался на уровне nginx без memcache:

Server Software:        nginx/0.5.33
Server Hostname:        xxxx
Server Port:            80

Document Path:          /ssi/1.html
Document Length:        177837 bytes

Concurrency Level:      100
Time taken for tests:   3.088 seconds
Complete requests:      500
Failed requests:        0
Broken pipe errors:     0
Total transferred:      97458740 bytes
HTML transferred:       97379006 bytes
Requests per second:    161.92 [#/sec] (mean)
Time per request:       617.60 [ms] (mean)
Time per request:       
6.18 [ms] (mean, across all concurrent requests)
Transfer rate:          31560.47 [Kbytes/sec] received

Результаты когда ответ формировался на уровне nginx с memcache:

Server Software:        nginx/0.5.33
Server Hostname:        
100lives-dev.kg
Server Port:            80

Document Path:          /ssi/1.html
Document Length:        177837 bytes

Concurrency Level:      100
Time taken for tests:   20.145 seconds
Complete requests:      500
Failed requests:        431
   (Connect: 0, Length: 431, Exceptions: 0)
Broken pipe errors:     0
Total transferred:      99889055 bytes
HTML transferred:       99811513 bytes
Requests per second:    24.82
 [#/sec] (mean)
Time per request:       4029.00 [ms] (mean)
Time per request:       40.29 [ms] (mean, across all concurrent requests)
Transfer rate:          4958.50 [Kbytes/sec] received

Результаты на лицо, тестировал всё на одной машине.
Если еще убрать ненужные итерации связанные с block и virtual, наверняка производительность повысится.

Хотелось бы услышать ваше мнение по этим результатам, Игорь?

C Уважением Вячеслав.
Hello!


Second var! If youd take a look at any web site, you will notice, that almost all of the pages on this given
site are pretty static in their nature. Or course, this site could have some dynamic elements
like login field or link in the header, some customized menu elements and some other things
But entire page could be considered static in many cases. When I started thinking about my
sites from this point of view, I understood, how great it would be to be able to cache entire
page somewhere (in memcache for example) and be able to send it to the user without any requests
to my applications, which are pretty slow (comparing to memcache ;-) ) in content generation. Then
I came up with a pretty simple and really powerful idea Il describe in this article. An idea of
caching entire pages of the site and using my application only to generate small partials of the
page. This idea allows me to handle hundreds of queries with one server running pretty slow
(yeah! it is slow even after all optimizations on MySQL side and lots of tweaks in sites code)
Ruby on Rails application. Of course, the idea is kind of universal and could be used with any
back-end languages, technologies or frameworks because all of them are slower then memcache in
content generation So, first of all, let me describe tools I use in my solution (but it does
not mean, that you must use the same software - it is just for example): If youd take a look
at any web site, you will notice, that almost all of the pages on this given site are pretty
static in their nature. Or course, this site could have some dynamic elements like login
field or link in the header, some customized menu elements and some other things But entire
page could be considered static in many cases. When I started thinking about my sites from
this point of view, I understood, how great it would be to be able to cache entire page
somewhere (in memcache for example) and be able to send it to the user without any requests
to my applications, which are pretty slow (comparing to memcache ;-) ) in content generation.
Then I came up with a pretty simple and really powerful idea Il describe in this article. An
idea of caching entire pages of the site and using my application only to generate small parti
als of the page. This idea allows me to handle hundreds of queries with one server running pr
etty slow (yeah! it is slow even after all optimizations on MySQL side and lots of tweaks in si
tes code) Ruby on Rails application. Of course, the idea is kind of universal and could be used
with any back-end languages, technologies or frameworks because all of them are slower then memca
che in content generation So, first of all, let me describe tools I use in my solution (but it does
not mean, that you must use the same software - it is just for example): If youd take a look at any
web site, you will notice, that almost all of the pages on this given site are pretty static in their
nature. Or course, this site could have some dynamic elements like login field or link in the header, so
me customized menu elements and some other things But entire page could be considered static in many cases
. When I started thinking about my sites from this point of view, I understood, how great it would be to be
able to cache entire page somewhere (in memcache for example) and be able to send it to the user without any
requests to my applications, which are pretty slow (comparing to memcache ;-) ) in content generation. Then
I came up with a pretty simple and really powerful idea Il describe in this article. An idea of caching en
tire pages of the site and using my application only to generate small partials of the page. This idea allows
me to handle hundreds of queries with one server running pretty slow (yeah! it is slow even after all optimi
zations on MySQL side and lots of tweaks in sites code) Ruby on Rails application. Of course, the idea is ki
nd of universal and could be used with any back-end languages, technologies or frameworks because all of the
m are slower then memcache in content generation So, first of all, let me describe tools I use in my solution
(but it does not mean, that you must use the same software - it is just for example):