On 2 April 2012 22:25, Stuart Dallas <stuart@xxxxxxxx> wrote: > On 2 Apr 2012, at 15:37, Simon wrote: > > > On 2 April 2012 14:27, Stuart Dallas <stuart@xxxxxxxx> wrote: > >> On 2 Apr 2012, at 14:12, Simon wrote: > >> > >> > Thanks Maciek > >> > > >> > On 2 April 2012 10:37, Maciek Sokolewicz <maciek.sokolewicz@xxxxxxxxx > >wrote: > >> > > >> >> On 02-04-2012 10:12, Simon wrote: > >> >> > >> >>> Thanks Simon. you got my hopes up there for a second. > >> >>> > >> >>> From the php docs page: > >> >>> > >> >>> Critics further argue that it is pointless to use a Singleton in a > Shared > >> >>>> > >> >>> Nothing Architecture like PHP where objects are unique>within the > Request > >> >>> only anyways. > >> >>> > >> >>> I want the the singleton class to be global to the entire > application (ie > >> >>> shared "by reference" across all requests). I'd agree with the above > >> >>> critics that if you have to instantiate your singleton for each > request, > >> >>> it's rather pointless. > >> >>> > >> >>> Well, that's simply not possible due to the "shared nothing > paradigm". > >> >> If you want to share, you need to either share it via another medium > (such > >> >> as a database, as has been suggested a dozen times already) or > switch to a > >> >> different language. > >> > > >> > > >> > > >> >> PHP is based on this paradigm, and you should not expect of it to > violate > >> >> it just because you want to do things a certain way, which is not > the PHP > >> >> way. > >> >> > >> > > >> > The existence of memcached, shm and apc_fetch tell me that PHP already > >> > accepts the need for sharing data between processes. All I'm arguing > for is > >> > the ability to share the data by reference rather than by copy. > >> > >> > >> As already mentioned several times the closest you will get is shared > memory (as used by APC), but you can't access that by reference because > shared read/write resources need controlled access for stability. > > > > I know. I understand that (and the issues with locking that might arise > if truly shared memory was available). > > > >> I can't find any material that explains how the .net framework > implements application variables. You mentioned earlier that you *know* > that when you access them you do so by reference. Do you have a source for > this knowledge or is it some sort of sixth sense? > > > > Source: 10+ years as an ASP and ASP.NET developer. > > Wow. As knowledge goes that's up there with "I believe it therefore it is." > I don't understand your point. > > > Having looked for documentation, I agree, it's utterly terrible. It's as > if even Microsoft themselves don't fully understand the advantages that > application variables give them over the competition. (Though they're > hardly likely to be forthcoming about helping others implement similar > features). > > > > Here's some stuff I did find: > > > > > http://www.codeproject.com/Articles/87316/A-walkthrough-to-Application-State#e > > This article explains basically how application variables work. It > doesn't specifically mention passing by reference but it discusses thread > safety at some length so you might infer that implies passing by reference. > > "can cause performance overhead if it is heavy" > You certainly have to be careful how you use it (as you do any tool). | And you want to store petabytes of data in there. Smart. No, I want to store 50 - 200Mb. At some point in the somewhat distant future I can imagine larger amounts of shared storage between required. Up to and including petabytes of data when such large amounts of RAM become practical. This does not have to cause overhead. The author was suggesting caution to protect people who aren't sure what they're doing. This can be done with "no" performance overhead (so long as you have the physical RAM). > > Anyway, that page says nothing about whether it's accessed by reference. > It implies that writes are atomic, which in turn implies that there is > something in the background controlling write access to the data. > > As for reading the data being done via references there is nothing in that > article to suggest that. > > > http://msdn.microsoft.com/en-us/library/ff650849.aspx > > Here is a more technical discussion about the singleton class is > implemented in .NET. Application variables are provided by an instance of a > singleton class (the HttpApplication class). > > Looks no different to the way you'd implement a singleton in PHP (as > expected - as a concept it doesn't generally change between languages). > Just because the HttpApplication class is a singleton doesn't mean that > when you request data from it you get it by reference. > Could we just for the sake of argument, just accept that it does actually pass by reference between threads, but not between processes ? It does - is that really so hard to believe ? > > > > http://stackoverflow.com/questions/1132373/do-asp-net-application-variables-pass-by-reference-or-value > > Stack overflow question from someone actually wanting to get a *copy* of > an application variable rather than a reference. > > According to that page scalar values are returned by value, objects are > returned as a copy of the reference. Based on that, it would appear that > you are correct as far as objects are concerned. However, the advice given > on several pages I've found, including at least one that you've specified, > is to use application variables lightly and sparingly. It's not something > that should be used for petabytes of data, mainly because it's all STORED > IN MEMORY. > see previous comments about petabytes. 50Mb or even 5GB is fine to store in Applications variables if you have the RAM. > > > So, if you read enough of this stuff, you'll find out that a .NET > website (an IIS application in MS parlance) runs in a multi-threaded single > process. Application variables (and singleton classes) are shared by > reference between all threads. It is possible to run an IIS application > over multiple processes (to take advantage of multiple processors / server > farms for example) but then the Application variables are not shared at > all. (This is then pretty comparable to the situation with node.js except > that node is not multi-threaded) > > Single process. Yes. Precisely. PHP *DOES NOT WORK LIKE THIS* and probably > never will, therefore it's not comparable. And why do you insist on > comparing anything with Node.js? Node is specifically single-process and, > as far as the JS developer is concerned, single-threaded. Node can't share > data across processes in the same way PHP can't. They're also completely > different architectures... Node implements the web server within the Node > process, PHP does not. It's not logical to say that an apple should be like > an orange. > I'm trying to point out an area where PHP is currently at a significant performance disadvantage yet has the possibility to turn this to significant advantage by "simply" enabling apc_fetch to returning a reference rather than a value. Both .NET and node.js both currently have a very significant performance advantage due to the ability to share data between requests by reference, rather than by copy as per php. If apc_fetch were to implement this behaviour PHP would gain a significant performance advantage because it could share objects between processes compared .NET's ability to only share between threads (and node's single thread). > > I don't understand why we're still talking about this. The architecture of > PHP does not make sharing data by reference possible, regardless of whether > that's how ASP.net works. You may choose not to want it. But that doesn't mean it's impossible. > It's irrelevant and frankly I couldn't care less (which I think I've > mentioned before). I used to use ASP and ASP.net, so I am familiar with > application variables, but I've never missed them since moving on to other > technologies. This could be related to the fact that when I moved away from > ASP I also moved on to far higher levels of traffic than I had ever dealt > with before. > > > You said that memcached was slow compared to the .net application > variables; of this I have no doubt. But again, that's irrelevant. The .net > application variables cannot scale beyond a single process; memcached can > comfortably scale to many thousands of servers and beyond. > Totally agree. One of the links I posted even suggested memcache at this point. However, you still might store data locally in Application variables (or more likely the .NET cache) to saving hitting the relatively slow memcached. > > I use a combination of generated PHP files (for things that don't change > one the app is running), memcached (for things that do), and many other > technologies to build web applications that serve many millions of users > every day, and I have no complaints. Per-process (or even per-server) > application variables never cross my mind - they just don't provide any > significant benefit. > > If you want PHP to work the way .net works, modify PHP yourself or pay > someone to do it for you, because I practically guarantee that you'll find > next to no support for moving away from the shared-nothing architecture of > the PHP core. > This may happen > > Alternatively... stick to ASP.net. I'm sorry that I appear to be pissing you off. It's cool if you want to maintain a "shared nothing" architecture (whilst ironically using apc_fetch, shm and memcached) > > I'm done. > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ >
