Project

General

Profile

Todo » History » Revision 8

Revision 7 (icy, 2009-02-10 23:55) → Revision 8/63 (nitrox, 2009-03-22 21:57)

h1. small todo list 

 * workers 
 ** out-of-fd handling should be (only) in the main worker 

 * implement stat-caching with extra threads 
 * add per plugin+virtual-request specific data 
 * accesslog 
 * physical.* conditionals 
 * regexp support 
 * ipv6 support 

 * angel 
 ** zero downtime restarts 
 ** fd passing 
 ** backend spawning with different uid/gid 
 ** log rotation (or use the zero downtime restart?) 

 * throttling 
 ** each connection gets a "magazine" that represents the amount of bytes it can send at the moment 
 ** when sending data, decrease the magazine 
 ** if magazine reaches 0, remove EV_WRITE for the sockwatcher and put connection at the end of the throttling queue 
 ** each N milliseconds (maybe 500, configure via setup?), check if there are waiting connections in the queue and rearm if waiting for > N ms 
 ** when rearming a connection, add number of allowed bytes to the magazine and set EV_WRITE again  
 ** add throttling via "pools". all connections in a specific pool share a magazine which enables throttling of all connections in a vhost for example 
 ** add throttling by ip (somewhat more complex) 

 * log 
 ** scheme:// prefix 
 ** write logs directly out in startup phase 

 * server-status overview 
 ** if server.max-keepalive-idle can be set for host/url/filetypes/<whatever> show the last request in keep-alive state to make it visible where the client entered that state and maybe show sth. like 23/120, client entered that state 23s ago, will idle away after a total of 120s 

 * implement better counter_format(): allow output like "10 961 KiB" 

 * find good hashing algorithms for ipv6 and memory addresses 

 * add mechanism to store plugin data specific to client ip address. can be used for bandwidth throttling, limit requests per second, limit concurrent requests etc 
 ** what would be the fastest algorithm for this task? hashtable, some kind of tree (red-black?) etc 
 ** a lot of inserts, deletes and lookups 
 ** has to be shared among all workers so locking needed