Menu
▾
▴
naviserver-devel
|
From: Vlad S. <vl...@cr...> - 2006-01-12 04:16:35
|
Hi, I have another idea for you to check: Will it be usefull to have special writer thread that will send multiple files in async mode to multiple clients. For example if i serve big ISO or movie files and have many connections, currently they all use conn thread for along time until the whole file is sent. Instead we can mark the conn to be used in writer thread and release conn thread for other requests and in the meantime the writer thread will send multiple FDs to clients in one big loop. Currently it is possible to simply change ConnSend in connio.c to submit open descriptor to the writer queue and return marking the connection so usual NsClose will not close actual connection socket. Then write thread will be simple loop reading small chunks from every file and sending to corresponding socket. Does it make sense? -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-01-12 08:03:35
|
Am 12.01.2006 um 05:19 schrieb Vlad Seryakov:
>
> I have another idea for you to check:
:-)
>
> Will it be usefull to have special writer thread that will send
> multiple files in async mode to multiple clients. For example if i
> serve big ISO or movie files and have many connections, currently
> they all use conn thread for along time until the whole file is sent.
That is precisely what I had in mind and have written that in one of
the recent emails.
> Instead we can mark the conn to be used in writer thread and
> release conn thread for other requests and in the meantime the
> writer thread will send multiple FDs to clients in one big loop.
Kindof.
>
> Currently it is possible to simply change ConnSend in connio.c to
> submit open descriptor to the writer queue and return marking the
> connection so usual NsClose will not close actual connection
> socket. Then write thread will be simple loop reading small chunks
> from every file and sending to corresponding socket.
>
> Does it make sense?
I believe Stephen had some remarks. They were originally ment
for the spool thread but can be applied here.
Quote:
What happens to the conn thread after this? It can't wait for
completion, that would defeat the purpose.
Do traces (logging etc.) run now, in the conn thread, or later in a
spool thread? If logging runs now, but the upload fails, the
log will
be wrong. If traces run in the spool threads they may block.
I was also thinking that perhaps a spooler thread might be re-used
for this, although I would have nothing against a specialized thread
doing this sort of work.
With this approach, even the Fastpath code could pass the socket
to the "writer" thread making all even more scalable. The connection
thread could only be used for generating dynamic content, whereas the
writer thread could handle all static content serving.
This makes very much sense to me.
Zoran
|
|
From: Gustaf N. <ne...@wu...> - 2006-01-12 08:56:01
|
Vlad Seryakov wrote: > > Hi, > > I have another idea for you to check: > > Will it be usefull to have special writer thread that will send > multiple files in async mode to multiple clients. For example if i > serve big ISO or movie files and have many connections, currently they > all use conn thread for along time until the whole file is sent. > Instead we can mark the conn to be used in writer thread and release > conn thread for other requests and in the meantime the writer thread > will send multiple FDs to clients in one big loop. this is exactly what we are doing in our production system, and what the code posted in http://sourceforge.net/mailarchive/message.php?msg_id=14351395 does. With the recent change in naviserver, that zoran put in, this code runs without a patch in naviserver (provided you have the tclthread library and the xotcl-support from aocs/packages/xotcl-core installed). the recent discussion was however, to generalize this further and use such thread for sending and receiving, thus the proposed name "spooling-thread". -gustaf > > Currently it is possible to simply change ConnSend in connio.c to > submit open descriptor to the writer queue and return marking the > connection so usual NsClose will not close actual connection socket. > Then write thread will be simple loop reading small chunks from every > file and sending to corresponding socket. > > Does it make sense? > |
|
From: Zoran V. <zv...@ar...> - 2006-01-12 09:20:45
|
Am 12.01.2006 um 09:55 schrieb Gustaf Neumann: > the recent discussion was however, to generalize this further and > use such thread for > sending and receiving, thus the proposed name "spooling-thread". Having such specialized thread as part of the server is great gain (no external modules, optimal speed, etc). Later on we can go to further extent and incorporate some kind of AIO in the thread to scale it even further up. The built-in fastpath code can transparently gain from this thread by delegating the dumb work of copying bytes from files to sockets and releveing the connection thread for real dynamic content tasks. IOW there are many reasons to make this as compact and as fast as possible and built into the server. So, we'll have a real beast capable of equally serving static AND dynamic content with the highest possible speed. I do not know how much work that be, but it seems to me that a spool-thread could take this task. Depending on the number of CPU's in the box, we might start one or two or four such things. As the GHz-frenzy has deteriorated and more chip makers produce dual/quad chips we'll immediately gain from the hardware. From the API side, we could re-route some commands sending output to transparently use this (new) infrastructure w/o programmer's influence. Well, there are MANY reasons why we'd opt to do it within the server as oposed to a Tcl-crafted solution. The proof of concept is already done, as you have very good experience with the thing, by using the trick with channel passing and a dedicated event-loop based thread. We'd really have to elevate it to a higher level with a writer or spooler or writer/spooler thread, however it eventually gets implemented. I'm really excited about all this... ;-) Cheers Zoran |
|
From: Vlad S. <vl...@cr...> - 2006-01-12 14:41:32
|
I did some preliminary coding and it works and the speed of downloading 2 simultaneous huge files are the same on average with current model, test are not very usefull because i tested on one computer only. I am attaching 2 files that i modified but more though and work should be done, currently it supportd only big files not in chunked mode returned by fastpath, but i think this is more than enough, all other dynamic content will go as usual. The WriterThread is at te end of driver.c and connio.c was modified in ConnSend function only. Yes, the logging and running atclose procs is the open question, i would run it in the conn thread. The parts between #ifdef #endif in WriterThread is experiments and they should be removed, it slowed down the server significantly. Zoran Vasiljevic wrote: > > Am 12.01.2006 um 09:55 schrieb Gustaf Neumann: > >> the recent discussion was however, to generalize this further and use >> such thread for >> sending and receiving, thus the proposed name "spooling-thread". > > > Having such specialized thread as part of the server is great > gain (no external modules, optimal speed, etc). Later on we > can go to further extent and incorporate some kind of AIO > in the thread to scale it even further up. The built-in fastpath > code can transparently gain from this thread by delegating > the dumb work of copying bytes from files to sockets and releveing > the connection thread for real dynamic content tasks. > > IOW there are many reasons to make this as compact and as fast > as possible and built into the server. So, we'll have a real > beast capable of equally serving static AND dynamic content > with the highest possible speed. > > I do not know how much work that be, but it seems to me that > a spool-thread could take this task. Depending on the number > of CPU's in the box, we might start one or two or four such > things. As the GHz-frenzy has deteriorated and more chip makers > produce dual/quad chips we'll immediately gain from the hardware. > > From the API side, we could re-route some commands sending output > to transparently use this (new) infrastructure w/o programmer's > influence. > > Well, there are MANY reasons why we'd opt to do it within the server > as oposed to a Tcl-crafted solution. The proof of concept is already > done, as you have very good experience with the thing, by using the > trick with channel passing and a dedicated event-loop based thread. > We'd really have to elevate it to a higher level with a writer or > spooler or writer/spooler thread, however it eventually gets implemented. > > I'm really excited about all this... ;-) > > Cheers > Zoran > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X