Robert Collins wrote:
I don't think it is, it's a natural assumption that the same user will not be making the same request twice at the same time.I certainly hope it's uncommon!
Yes, you are right, but if I put the syncronisation in the webserver I have already lost because, I'll have an apache process sucking mud waiting for the proper locks.Squid really isn't the point to fix race conditions: syncronisation is your friend, in the server.
The only way to correctly fix this in the application is to check if the job is already done and react intelligently to that, come to think of it that might be a whole lot better solution.
I have seen the light and will shut up about that point now.
Do you mean webserver as in ip X, ip Y, or as in apache forked() X, apache forked() Y.
Yes.
Different apache forks, not different machines.
Yes, but that will not happen before the request has been run and that means that you have just run a request for a user who has given up and submitted a new one, iow: because the content can never be cached you have lost.squid will stop serving once write() returns an error.
Yes, I know, Henrik told me, no I don't send non-cachable data marked as cachable.Squid offloads disk io, so writing cachable data to disk won't affect performance much. If your app is sending non-cachable data marked as cachable, then you have a bug!
>> [lock webserver access by session id]
Not at all, there /are/ no graphics, pages typically consist of two things, the dynamicly generated page and a static stylesheet, the stylesheet will be cached either in the client or squid.This seems very painful to me - you will slow down graphics as well as database pages.
Anyway, this was a stupid idea, I'll go and fix my application in stead:)
Luckily it's rare to have people who use proxies and those that are deserve to be punished ;-)header (like X-calm-down-beavis).This won't work. If you have *any* downstream proxies,
No not really, but it really does seem like very very few users sit behind a proxy and in the situation where people are likely to need this hack they are also likely to have read the pre-sales-instructions that tell them to turn off their proxy.
This may sound like bs, but the root of the problem is that when we sell tickets for events that usually sell out the users go non-liniear in their frenzy to get their hands on tickets and they will happily create an account or update it weeks ahead of the release, so telling them to turn off proxies is not that big a deal in the grand scheme of things.
[session webserver affinity]
>
* This needs two new (and worthwhile) concepts in squid - 1) session ID awareness, and 2) an access list for allowing connection reuse on aYes, I do think this is a good idea generally, if a webserver has just served a request then it is likely to be faster at serving a new request for the same user as some data that user works with will be cached.
per-forwarding-attempt basis.
Hmm, how, where? I'd be more than happy to spend some RAM to get more free apaches.* Ah, squid doesn't start new processes :}. Anyway, this is exactly what squid does today, with one exception: squid doesn't read the entire object in advance of the client - it only reads a few kb ahead - to avoid huge memory races. This is tunable IIRC.
* Again, this is *exactly* what squid does today.
Great minds think alike :-) -- Regards Flemming Frandsen - http://dion.swamp.dk PartyTicket.Net co founder & Yet Another Perl Hacker
