Re: [naviserver-devel] Writer Thread proposal

[Vlad S. <vl...@cr...>]

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/